第3章 数字证书与CA体系
你想想看，浏览器地址栏里那把绿色小锁，凭什么就能保证你和服务器之间的通信是加密的？背后就是数字证书和CA体系在撑着。我当年刚接触TLS时，觉得证书就是个装着公钥的文件，后来踩了坑才明白——证书里藏着的信任链条，才是整个安全的根基。
3.1 数字证书到底是什么
说白了，数字证书就是一个电子版的身份证。它把“某个公钥”和“某个实体（比如域名、公司）”绑定在一起，再由一个有公信力的机构盖个章。这个盖章的过程，就是CA的职责。
一个标准的X.509证书，长什么样？我直接列出来：
| 字段 | 含义 | 我遇到过的问题 |
|---|---|---|
| 版本号 | 大多是v3（支持扩展项） | 老系统还在用v1，扩展信息读不出来 |
| 序列号 | CA唯一分配给证书的编号 | 吊销时靠它找到对应证书 |
| 签名算法 | CA使用的哈希+加密算法 | 比如SHA256withRSA |
| 颁发者(Issuer) | 签发该证书的CA名称 | 注意：根证书的颁发者就是自己 |
| 有效期 | notBefore ~ notAfter | 过期证书会引起连接失败（我踩过） |
| 使用者(Subject) | 证书持有人的域名或组织 | 通配符证书啊，主域名也要匹配 |
| 公钥 | RSA或者ECC的公钥 | 长度至少要2048位了 |
| CA签名 | 用CA私钥对整个证书做的数字签名 | 这是防篡改的核心 |
| 扩展项 | Key Usage、Subject Alt Name等 | 缺失SAN会导致浏览器报“不安全” |
3.2 CA体系：谁给信任背书的？
CA（Certificate Authority）就是那个盖章的人。但任何一个CA都能签证书的话，世界就乱了。所以实际用的是证书链结构——类似一个树形信任网。
我画了一张图，帮你理清脉络：
核心结构很简单：根CA自签名，它签出中间CA，中间CA再签出终端证书（比如你的网站证书）。客户端拿到服务器发来的完整证书链，从叶子节点一路往上验证，直到碰到自己本地预置的根证书——那个就叫“信任锚”。
3.3 证书验证流程（客户端视角）
为什么需要完整证书链？我记得有一次，做SDK接入时服务端只发了叶子证书，客户端报“无法找到颁发者”。这就是缺少中间CA证书的典型错误。
客户端验证通常分三步：
- 路径构建：从叶子证书开始，根据Issuer字段找到上一级CA证书，构建出一条证书链。
- 路径验证：用上一级证书的公钥，验证下一级证书上的签名。一级一级往上，直到根证书。
- 信任决策：如果顶点证书正好是客户端信任的根CA，验证通过；否则报错。
另外，验证过程还会检查：证书是否被吊销（通过CRL或OCSP）、证书用途是否匹配（比如服务器证书不能当CA证书用）、域名是否匹配SAN字段等。每一项都有可能成为连接失败的原因。
3.4 自签名证书 vs CA签发证书
开发阶段用自签名证书很方便，但生产环境必须用CA签发的证书。我做个对比：
| 维度 | 自签名证书 | CA签发证书 |
|---|---|---|
| 可信来源 | 没有第三方背书 | 受主流操作系统/浏览器信任 |
| 浏览器提示 | 红色警告“不安全” | 绿色小锁 |
| 撤销支持 | 通常无法统一管理 | 可通过CRL/OCSP撤销 |
| 适用场景 | 内部测试、开发环境 | 生产环境、对外服务 |
| 证书链 | 仅单证书 | 根CA+中间CA+叶子 |
| 我建议 | 自己用openssl生成，方便快捷 | 购买或使用Let's Encrypt免费证书 |
Let's Encrypt的自动续签方案，我个人觉得特别适合中小团队。但注意，它使用的中间CA（R3）也需要放在证书链里，别漏了。
3.5 证书链部署的实操要点
SDK接入改造中，你可能会遇到两种常见的证书链部署方式：
- 全链拼接：服务器配置里把根证书、中间CA、叶子证书拼成一个PEM文件下发。nginx的ssl_certificate就支持这样配置。
- 单证书+中间CA缓存：部分SDK自己管理中间CA的获取（比如通过AIAC扩展下载）。但为了保险，我习惯直接全链下发，省得客户端自己去爬。
下面是一个nginx的配置示例，我演示一下怎么拼接：
server {
listen 443 ssl;
server_name example.com;
# 全链证书（按照 叶子→中间CA→根 的顺序拼接）
ssl_certificate /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/example.com.key;
# 其他安全配置...
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
}fullchain.pem的内容大致是：
-----BEGIN CERTIFICATE-----
（叶子证书）
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
（中间CA证书）
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
（根CA证书，可选，但建议加上）
-----END CERTIFICATE-----3.6 不得不提的吊销机制
证书不是发了就永久的。CA可以通过CRL（证书吊销列表）或OCSP（在线证书状态协议）来宣告某个证书作废。比如私钥泄露了，就得吊销。我在做SDK改造成时，曾经遇到一个奇怪的问题——某张证书明明在有效期内，但客户端就是连不上。查了半天，发现是OCSP stapling返回了“revoked”。
所以，如果你的SDK支持OCSP stapling，建议开启（nginx的ssl_stapling on），可以大幅提高验证效率，还能保护隐私（客户端不需要自己去查OCSP服务器）。
嗯，关于数字证书与CA体系，核心就是这些。记住了，证书链就是信任的传递：从根到叶子，一级签一级，客户端只用相信自己预设的根。理解了这一点，后面的TLS握手细节就不难了。