https，客户端拿到服务端的证书后是怎么验证证书的合法性？｜阿里巴巴客户端面经解析

60 秒回答模板

客户端拿到服务端证书后，不会直接相信证书里的公钥，而是做一组身份和信任校验。首先根据服务端返回的站点证书和中间 CA 证书构建证书链，最终要追溯到本地系统、浏览器或应用信任库里的根 CA。然后客户端会用上一级证书的公钥验证下一级证书签名，逐级确认内容没有被篡改，并确认最终根证书是可信任锚。接着检查当前访问主机名是否匹配证书中的 Subject Alternative Name，检查当前时间是否落在 Not Before 和 Not After 之间，检查 Key Usage 和 Extended Key Usage 是否允许 TLS 服务端认证。之后还可能通过 OCSP、OCSP Stapling 或 CRL 判断证书是否被吊销。证书验证还要和 TLS 握手绑定：服务端必须证明自己持有证书对应私钥，TLS 1.3 中通过 CertificateVerify 对握手上下文签名。移动端或高安全场景还可能做证书固定，校验证书、公钥或 SPKI 摘要是否匹配预置值。任何环节失败，例如证书过期、域名不匹配、缺少中间证书、根不受信任、用途错误、吊销或 pin 不匹配，都应该导致连接不可信。

考点 构建证书链

主线 逐级签名验证

易错点 只看证书是否过期，忽略证书链、域名、用途和吊销状态。

深入解析

构建证书链

服务端在握手中发送站点证书，通常还会带中间 CA 证书。客户端要把站点证书、中间证书和本地信任库中的根 CA 串成一条可信路径。如果缺少中间证书、链顺序异常或找不到可信根，证书链就不能成立。

逐级签名验证

每一级证书都由上一级 CA 签发。客户端用签发者证书中的公钥验证被签发证书的数字签名，逐级确认内容没有被篡改，也确实由对应 CA 签发。仅有证书内容本身是不够的，必须验证签名链是否完整可信。

信任锚确认

证书链最终必须落到客户端信任库中的根 CA，或应用明确配置的信任锚。根 CA 通常不是服务端临时发来的，而是系统、浏览器或运行时预置的信任基础。根不被信任时，签名数学上正确也不能通过。

身份与时间

客户端要把访问的主机名与证书里的 Subject Alternative Name 匹配，现代校验主要看 SAN 而不是只看 Common Name。还要检查证书是否在有效期内，设备时间错误、证书过期或尚未生效都会导致失败。

用途与吊销

证书还要满足 Key Usage 和 Extended Key Usage，服务端证书通常需要 serverAuth。客户端可能通过 OCSP、OCSP Stapling 或 CRL 检查吊销状态，用来发现私钥泄露、误签发或不应继续使用的证书。

私钥证明

验证证书还不等于验证握手完成。服务端必须证明自己持有证书对应私钥，现代 TLS 会把这个证明和握手上下文绑定，防止攻击者只转发一张合法证书却无法完成身份认证，也避免密钥协商被单独替换。

证书固定

移动端可以额外做证书、公钥或 SPKI 摘要固定，这是标准链路校验之外的加强手段。pinning 能降低 CA 被误信任或滥用的风险，但必须设计证书轮换、备用 pin 和灰度更新，否则会造成线上连接失败。

易错点

只看证书是否过期，忽略证书链、域名、用途和吊销状态。
以为证书里的公钥可以直接信任，没有经过 CA 信任链验证。
以为根 CA 是服务端发来的，忽略本地信任库的作用。
只看 Common Name，不检查 Subject Alternative Name。
认为 pinning 可以随便固定叶子证书，不设计备用 pin 和更新策略。

面试官追问

为什么验证证书链后还要验证域名？

证书链只能说明证书由可信 CA 签发，不能说明它属于当前访问的主机。域名匹配用于确认这个证书确实绑定了当前请求的服务身份。

根 CA 的公钥从哪里来？

通常来自操作系统、浏览器或运行时内置的信任库。移动端应用也可以通过网络安全配置或自定义信任锚扩展信任来源，但必须谨慎维护更新。

中间证书缺失为什么会失败？

客户端需要完整路径才能从站点证书追溯到可信根。如果服务端没有发送中间证书，客户端又无法本地补全，就无法建立可信链。

证书固定通常固定什么？

实践中常固定 SPKI 哈希或公钥摘要，而不是完整叶子证书。这样证书续期时只要密钥不变，就不一定需要同步更新应用。