📚 课程目录第3章公钥基础设施(PKI)

3. 公钥基础设施(PKI)：CA机构、数字证书(X.509)、证书链、证书吊销(CRL/OCSP)

聊到TLS双向认证，有个东西绕不开——PKI。说白了，它就是一套让互联网上互不相识的双方能放心交换公钥的信任体系。我刚开始接触时也觉得这玩意儿挺虚的，不就是一堆证书嘛。直到有一次在生产环境排查双向认证失败，折腾了整整两天，最后发现是证书链没配全。嗯，从那以后我再也不敢小看PKI了。

3.1 PKI的核心角色：CA机构

CA（Certificate Authority），证书颁发机构，是整个PKI体系的信任锚点。你可以把它理解成网络世界的"公安局出入境管理处"——负责核实身份、颁发证件。

CA的核心职责就三件事：

身份验证：申请者提交资料，CA核实其确实拥有对应域名或组织身份
证书签发：验证通过后，CA用自己的私钥对申请者的公钥和身份信息做数字签名
证书管理：维护证书生命周期，包括续期、吊销等

我个人习惯把CA分成两类：

类型	特点	典型用途
公共CA	根证书预埋在操作系统/浏览器中，全球信任	HTTPS网站、公开服务
私有CA	自建，根证书需手动分发到客户端	企业内部系统、IoT设备管理

我的经验：做硬件密钥双向认证时，我建议优先用私有CA。原因很简单——你控制根证书，就能控制整个信任边界。公共CA的证书万一被吊销，你连排查都得求人。

3.2 数字证书(X.509)：公钥的身份证

数字证书，就是公钥的"身份证"。它把公钥和持有者身份绑定在一起，再由CA签名担保。目前最通用的标准是X.509 v3。

一个X.509证书长什么样？我拆开给你看：

证书结构（X.509 v3）：
├── 版本号 (Version)
├── 序列号 (Serial Number)
├── 签名算法 (Signature Algorithm)
├── 颁发者 (Issuer)          ← 签发该证书的CA名称
├── 有效期 (Validity)
│   ├── 生效时间 (Not Before)
│   └── 失效时间 (Not After)
├── 主体 (Subject)           ← 证书持有者名称
├── 主体公钥信息 (Subject Public Key Info)
│   ├── 公钥算法
│   └── 公钥值
├── 颁发者唯一标识 (Issuer Unique ID) [可选]
├── 主体唯一标识 (Subject Unique ID) [可选]
└── 扩展项 (Extensions) [v3新增]
    ├── 密钥用法 (Key Usage)
    ├── 扩展密钥用法 (Extended Key Usage)
    ├── 主体备用名称 (Subject Alternative Name)
    └── 基本约束 (Basic Constraints)

这里有个关键点——扩展项。X.509 v3引入扩展后，证书才有了"用途"的概念。比如一张证书可以声明自己只能做服务器认证，不能做代码签名。我在项目中遇到过有人把客户端证书当服务器证书用，结果TLS握手一直报错，查了半天才发现是扩展密钥用法没配对。

3.3 证书链：信任的传递

你想想看，如果每个证书都直接由根CA签发，那根CA的私钥就得天天在线签名，风险太大了。所以实际部署中，我们用的是证书链——根CA签中间CA，中间CA再签终端证书。

证书链的结构是这样的：

信任锚（根证书）→ 中间CA证书 → 终端实体证书

每一级证书都由上一级签发，验证时从终端证书逐级向上追溯，直到信任锚。

为什么要这么设计？说白了就两个原因：

安全隔离：根CA私钥可以离线保存，只在签发中间CA时才拿出来用。就算中间CA被攻破，吊销它就行，根证书不受影响。
灵活管理：不同业务线可以用不同的中间CA，权限分开，互不影响。

验证证书链时，TLS客户端会做这么几步：

从服务器拿到终端证书和中间CA证书
用中间CA的公钥验证终端证书的签名
用根CA的公钥验证中间CA证书的签名
检查根证书是否在本地信任存储中

我曾经遇到一个坑：服务器只发了终端证书，没发中间CA证书。客户端本地又没有这个中间CA，结果验证链断了。嗯，这就是典型的"证书链不完整"问题。解决办法很简单——服务器配置时把中间CA证书一并带上。

下面这张图展示了完整的证书链结构和验证流程：

3.4 证书吊销：信任的撤回

证书还没到期，但私钥泄露了、员工离职了、域名换了——这时候怎么办？就得吊销证书。吊销机制就是告诉所有人："这张证书不再可信了，别用了。"

目前主流的有两种吊销方式：

方式	全称	工作原理	优缺点
CRL	证书吊销列表	CA定期发布一个被吊销证书的序列号列表	简单但有时延，列表会越来越大
OCSP	在线证书状态协议	实时查询某张证书当前是否被吊销	实时性好，但依赖CA在线服务

注意：OCSP有个"隐私问题"——每次查询都会告诉CA"我正在验证谁的证书"。解决办法是OCSP Stapling，由服务器定期从CA获取OCSP响应，握手时直接发给客户端，避免客户端直接查询CA。

我在项目中遇到过CRL的坑。有一次客户端验证证书时，下载的CRL文件有几十兆，每次握手都要下载一遍，延迟高得离谱。后来改成OCSP Stapling，问题才解决。所以我的建议是：

内网环境、设备数量少 → 用CRL，简单可控
公网环境、对实时性要求高 → 用OCSP Stapling
硬件密钥场景 → 强烈建议OCSP Stapling，因为硬件密钥本身计算资源有限，别让它去下载大文件

3.5 实战：用OpenSSL查看证书链

光说不练假把式。我带你用OpenSSL实际看看一张证书的完整链。假设你有一个服务器证书文件 server.crt：

# 查看终端证书详情
openssl x509 -in server.crt -text -noout

# 验证证书链（需要CA证书链文件 ca-chain.crt）
openssl verify -CAfile ca-chain.crt server.crt

# 查看证书的OCSP访问地址
openssl x509 -in server.crt -noout -ocsp_uri

# 手动发起OCSP查询
openssl ocsp -issuer ca-chain.crt -cert server.crt \
  -url $(openssl x509 -in server.crt -noout -ocsp_uri) -text

输出里重点关注几个字段：

Issuer 和 Subject —— 看谁签了谁
X509v3 Basic Constraints —— 看是不是CA证书
X509v3 Key Usage —— 看证书用途
Authority Information Access —— 看OCSP地址和CA证书下载地址

一个小技巧：我习惯用 openssl s_client -connect example.com:443 -showcerts 直接看服务器在TLS握手时发了哪些证书。如果发现链不完整，服务端配置大概率有问题。

好了，PKI这块的核心内容就这些。记住一句话：证书是公钥的身份证，CA是发身份证的公安局，证书链是信任的传递链，吊销机制是信任的撤回按钮。把这四个概念吃透，后面讲双向认证时你就能理解为什么硬件密钥要跟证书绑定在一起了。