X.509标准详解：证书结构、证书链与扩展字段
聊到证书管理，X.509 是个绕不开的标准。说实话，我刚开始接触 PKI 那会儿，看着证书里一堆字段也挺懵的。后来踩过几次坑，才真正理解每个字节的意义。
这一章，咱们就把 X.509 v3 证书掰开揉碎。从结构到链，再到那些关键的扩展字段，一次性说清楚。
X.509 v3 证书结构
一个 X.509 v3 证书，说白了就是一张数字身份证。它由三个主要部分组成：TBSCertificate（待签名证书信息）、签名算法标识和签名值。
我习惯把 TBSCertificate 看作证书的「本体」，签名则是「防伪标签」。本体里包含了持有者的身份信息、公钥、有效期等核心数据。签名算法告诉你怎么验证这个防伪标签。
核心结构一览：
- 版本号：目前主流是 v3（值为 2）。v1 和 v2 基本绝迹了。
- 序列号：CA 颁发的唯一编号，用于区分同一 CA 下的不同证书。
- 签名算法：CA 对证书签名时使用的算法，比如 sha256WithRSAEncryption。
- 颁发者：签发该证书的 CA 的 DN（Distinguished Name）。
- 有效期：包含 notBefore 和 notAfter，定义了证书的生效和失效时间。
- 主体：证书持有者的 DN。
- 公钥信息：持有者的公钥以及对应的算法。
- 扩展字段：v3 引入的灵活区域，用于附加约束和用途。
你可能会问，为什么要有版本号？嗯，这是为了向后兼容。v1 证书没有扩展字段，v2 加了一些但不够用，v3 才真正成熟。我在生产环境里几乎没见过 v3 以外的证书。
证书链：信任的传递
证书链，也叫信任链。它解决了一个核心问题：我凭什么相信你？
举个例子。你访问一个网站，服务器给你一张证书。你的浏览器不会直接信任它，而是会向上追溯——看是谁签发了这张证书，再往上查是谁签发了那个签发者，直到找到一个你本来就信任的根证书。
这个链条通常有三层：
- 根 CA：自签名证书，信任的起点。它没有上级，通常预装在操作系统或浏览器里。
- 中间 CA：由根 CA 签发，用于签发终端证书。引入中间层是为了安全——根 CA 的私钥可以离线保存，减少泄露风险。
- 终端证书：也叫叶子证书，直接用于 TLS、代码签名等场景。
我的经验： 我曾经接手过一个项目，对方直接把根证书当服务器证书用。虽然技术上能跑，但风险极高。根私钥一旦泄露，整个信任体系就崩了。正确的做法是根 CA 离线，中间 CA 在线签发。
验证证书链时，浏览器会从终端证书开始，逐级向上验证签名，直到根证书。每一步都要检查：签名是否正确、证书是否在有效期内、是否被吊销。
下面这张图展示了典型的证书链结构：
证书扩展字段：v3 的精髓
v3 证书之所以强大，就是因为扩展字段。它让证书不再只是一个身份标识，还能携带各种约束和用途信息。
我重点讲三个最常用的扩展：SAN、Key Usage 和 Extended Key Usage。
Subject Alternative Name (SAN)
SAN 解决了「一张证书支持多个域名」的问题。以前一个证书只能绑定一个 Common Name (CN)，现在通过 SAN 可以列出多个域名或 IP。
举个例子，一张证书的 SAN 可以同时包含：
example.comwww.example.comapi.example.com192.168.1.10
浏览器在验证时，会检查访问的域名是否在 SAN 列表里。如果不在，即使 CN 匹配，也会报错。
注意： 从 Chrome 58 开始，浏览器已经不再看 CN 字段了，只认 SAN。所以签发证书时，务必把需要的域名都加到 SAN 里。我曾经见过有人只填了 CN，结果上线后浏览器疯狂报错。
Key Usage
这个字段限制了证书的公钥能干什么。它是个位掩码，常见的用途包括：
| 用途 | 说明 |
|---|---|
| digitalSignature | 用于数字签名，比如 TLS 握手时的签名 |
| keyEncipherment | 用于加密密钥，比如 TLS 中传输对称密钥 |
| keyCertSign | 用于签发其他证书，只有 CA 证书才有这个位 |
| cRLSign | 用于签发证书吊销列表 (CRL) |
我建议你严格按照最小权限原则来设置。比如服务器证书通常只需要 digitalSignature 和 keyEncipherment，不要画蛇添足加上 keyCertSign。
Extended Key Usage (EKU)
EKU 比 Key Usage 更精细。它指定了证书的具体用途，比如：
serverAuth：用于 TLS 服务器身份验证clientAuth：用于 TLS 客户端身份验证codeSigning：用于代码签名emailProtection：用于电子邮件加密
一张证书可以同时有多个 EKU。但要注意，如果 EKU 字段存在，客户端会严格检查。比如一张只有 codeSigning 的证书，绝对不能用于 TLS。
避坑指南： 我曾经遇到过一个问题：中间 CA 证书的 EKU 里没有加 serverAuth，导致它签发的终端证书在 TLS 握手时被拒绝。后来查了半天才发现是 EKU 约束太严。所以签发中间 CA 时，EKU 要留够余地。
扩展字段对比
这三个扩展字段容易混淆，我整理了一个对比表：
| 扩展字段 | 作用范围 | 典型值 | 常见错误 |
|---|---|---|---|
| SAN | 域名/IP 绑定 | DNS:example.com, IP:192.168.1.1 | 漏填 SAN，只依赖 CN |
| Key Usage | 公钥用途 | digitalSignature, keyEncipherment | CA 证书漏加 keyCertSign |
| EKU | 证书应用场景 | serverAuth, clientAuth | 中间 CA 的 EKU 限制过死 |
小结
X.509 v3 证书的结构并不复杂，但细节决定成败。证书链保证了信任的传递，扩展字段让证书变得灵活而安全。