TLS 中的证书验证

如果不验证证书，攻击者就可以冒充服务器，与客户端建立 TLS 连接（中间人攻击）。证书验证可以确保您连接的是合法服务器，并且该服务器控制着相应的私钥。

关键字段包括：Subject（证书所有者）、SubjectAltName（DNS 名称/IP 地址）、Issuer（签名 CA）、Validity（notBefore/notAfter）、Public Key（公钥）和 Signature（签名）。浏览器会检查这些字段。

服务器证书 → 中间 CA 证书 → 根 CA 证书。根 CA 是自签名的，并预先安装在 OS/浏览器的信任存储区中。服务器会在 TLS 握手的 Certificate 消息中发送自己的证书和中间证书。

每张证书都由其上级颁发者签名。客户端会使用以下方式进行验证：使用 public_key(cert_{n+1}) 验证 signature(cert_n)。如果任一签名无效，整条链都会被拒绝。根证书之所以受信任，是因为它被预先安装，而不是因为验证了它的签名。

客户端会检查服务器主机名是否与证书的 Subject 或 SubjectAltName（DNS 条目）匹配。通配符（*.example.com）只能匹配一个标签。自 2000 年起，在匹配主机名时，SAN 优先于 CN。

客户端会检查证书链中每张证书是否满足 notBefore ≤ now ≤ notAfter。即使签名有效，过期证书也会被拒绝。证书有效期一直在缩短：目前浏览器将其上限限制为约 398 天。

CA 会发布证书吊销列表（CRL），其中包含已吊销证书序列号的签名列表。客户端会下载证书 CRL Distribution Points 扩展中提供的 CRL URL，并检查其中是否包含该序列号。

在线证书状态协议（OCSP）允许客户端向 CA 的 OCSP 响应器查询单张证书的状态。它比 CRL 更快，但会增加延迟。OCSP Stapling 让服务器在 TLS 握手中附带经过签名的 OCSP 响应。

CT（RFC 6962）要求 CA 将所有已签发证书记录到公开的、只能追加的日志中。浏览器会检查证书或 TLS 扩展中的签名证书时间戳（SCT）。这样可以防止错误签发的证书长期不被发现。

HTTP 公钥固定（HPKP，已弃用）以及移动应用中的证书固定，会固定某个特定的公钥或证书哈希。如果服务器提供了不同的证书，即使该证书本身有效，连接也会被拒绝，从而防止 CA 被攻破后的攻击。

ERR_CERT_AUTHORITY_INVALID：根证书不受信任。ERR_CERT_DATE_INVALID：证书已过期。ERR_CERT_COMMON_NAME_INVALID：主机名不匹配。NET::ERR_CERT_REVOKED：OCSP/CRL 表明证书已吊销。每种错误都对应某个具体验证步骤的失败。

OCSP Stapling 实现了什么效果？

TLS 中的证书验证包括信任链验证、签名检查、名称匹配、有效期检查和吊销检查。下一步：了解 TLS 历史上的攻击，以及 TLS 1.3 如何缓解这些攻击。