X.509 证书

X.509 证书通过颁发者签名，将主体公钥绑定到所声明的主体身份。 证书验证用于确定在特定协议和连接中是否可以接受这种绑定。 仅解析证书或仅验证其签名并不足够。

编码和证书结构 #

证书是 ASN.1 值，通常使用 DER 进行编码。PEM 是 DER 对象的 Base64 文本形式：

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

带签名的 tbsCertificate 包含版本、由颁发者唯一分配的序列号、颁发者 专有名称、有效期、主体专有名称、SubjectPublicKeyInfo (SPKI) 以及扩展。 外层证书还包含颁发者的签名算法标识符，以及对 tbsCertificate 的签名。 颁发者公钥不会作为单独的证书字段嵌入；需要通过构建到颁发者证书或信任锚 的路径来找到它。

TLS 使用的扩展 #

RFC 5280 扩展限制证书的使用方式：

• basicConstraints 标识 CA 证书和路径长度限制。
• keyUsage 限制 keyCertSign 或 digitalSignature 等操作。
• extendedKeyUsage 可以将用途限制为服务器身份验证或客户端身份验证。
• subjectAltName 携带用于 TLS 身份检查的 DNS 名称和 IP 地址。
• 主体密钥标识符和授权机构密钥标识符有助于路径构建，但不能替代签名验证。

TLS 客户端会将请求的 DNS 名称与 subjectAltName 进行验证。对于正确签发的 现代证书，通用名称不是通用的回退机制。有效时间、关键扩展、签名算法策略、 基本约束和密钥用途都会参与验证。

路径、吊销和固定 #

路径构建会从叶证书到本地配置的信任锚选择一系列颁发者。路径验证随后会 验证签名、时间、basicConstraints、路径长度和名称约束、密钥用途、关键扩展， 以及依赖方的算法和策略要求。如果应用程序使用证书策略，策略树可以限制可 接受的证书策略。服务器会传输此过程所需的中间证书，但信任锚通常由客户端 信任存储提供。

CRL 和 OCSP 提供吊销信息，但客户端行为因平台和协议而异。未经对实际客户端 群体进行测试，不得声称能够立即强制执行吊销。证书固定会增加公钥或证书约束； 它会带来运维恢复成本，因此仅应在定义了明确轮换流程的情况下使用。

使用 openssl x509 -in cert.pem -noout -text 检查字段。显示的 SHA-256 指纹是证书字节的摘要，用于带外比较；它不是身份凭证，也不能替代路径验证。

关于用于验证证书的 TLS 1.3 握手，请参阅 TLS 1.3。