3. PKI与证书体系基础
在 MQTT 的 mTLS 接入中，客户端和 Broker 双方都要出示证书，任何一方校验失败都会导致连接被拒绝。因此，理解证书从哪里来、由谁签发、如何被验证，是排查“证书明明配了却连不上”这类问题的前提。本节围绕 PKI（公钥基础设施）的核心构件展开，为后续配置 mTLS 打基础。
一、CA 与证书的信任起点
PKI 的核心角色是 CA（Certificate Authority，证书颁发机构）。CA 用自己的私钥对“某公钥属于某个主体”这一声明进行签名，生成证书。验证方只要拥有该 CA 的公钥（即 CA 证书），就能验证它签发的所有证书。
信任不是无限的，而是有起点的。这个起点就是根证书（Root CA Certificate）。根证书是自签名的，即签发者和被签发者是同一个主体。它通常离线保管，有效期很长（常见 10～20 年），只在需要签发中间证书时才启用。根证书一旦泄露，整个信任体系崩塌，所以工程上强调“根 CA 离线、中间 CA 在线”。
中间证书（Intermediate CA Certificate）由根 CA 签发，用于日常签发终端证书。引入中间层的好处是：即使中间 CA 被攻破，可以吊销中间证书而不必废弃根证书。中间 CA 可以有多个层级，但层级越深，验证链越长，握手开销越大，实践中一般不超过两级中间 CA。
二、服务器证书与客户端证书
终端实体证书分为两类：
- 服务器证书：绑定 Broker 的域名或 IP，客户端用它验证“我连的确实是目标 Broker”。关键字段是 SAN（Subject Alternative Name），现代 TLS 校验只看 SAN，不再看 CN。例如 MQTT Broker 部署在
mqtt.example.com，SAN 必须包含该域名，否则客户端会报hostname mismatch。 - 客户端证书：绑定设备或用户身份，Broker 用它验证“接入方是谁”。在 mTLS 中，客户端证书的 Subject 或 SAN 常被用作设备唯一标识，例如
CN=device-0001，Broker 可据此做 ACL 授权。
两者结构相同，区别在于扩展用途：服务器证书通常带 extendedKeyUsage = serverAuth，客户端证书带 clientAuth。若用途不匹配，即使签名有效也会被拒绝。
三、证书链与验证过程
证书链（Certificate Chain）是从终端证书到根证书的路径：服务器证书 → 中间证书 → 根证书。验证时，验证方从终端证书开始，逐级用上一级的公钥验证下一级的签名，直到命中本地信任库中的根证书。
这里有一个常见坑：Broker 在 TLS 握手中必须发送完整链（服务器证书 + 所有中间证书），但不发送根证书。因为根证书应在客户端信任库中。如果只发服务器证书而漏发中间证书，客户端会报 unable to get local issuer certificate。可以用 openssl s_client -connect mqtt.example.com:8883 -showcerts 检查服务端实际下发的链是否完整。
四、CRL 与 OCSP：吊销状态怎么查
证书在有效期内也可能因为私钥泄露、设备报废等原因需要提前失效，这就是吊销。验证方除了验证签名和有效期，还应检查吊销状态，否则一张已泄露的证书仍能通过校验。
CRL（Certificate Revocation List）是 CA 定期发布的吊销列表文件，包含所有被吊销证书的序列号。验证方下载 CRL 后，检查目标证书序列号是否在列表中。缺点是 CRL 会越来越大，且存在更新延迟——证书刚被吊销到新 CRL 发布之间有一段“窗口期”。
OCSP（Online Certificate Status Protocol）则是对单张证书的实时查询：验证方向 OCSP 响应器发送证书序列号，得到 good、revoked 或 unknown。它更及时，但引入了额外网络请求，且 OCSP 响应器本身可能成为可用性瓶颈。工程上常用 OCSP Stapling：由服务器在握手时把 CA 签名的 OCSP 响应“钉”在证书旁一起发给客户端，既保证实时性又减少客户端外联。
在 MQTT 场景中，如果设备数量大、网络受限，可以先用 CRL 做批量校验，再对关键设备启用 OCSP；若 Broker 与 CA 之间网络不稳定，应设置合理的吊销校验超时与降级策略，避免因 OCSP 不可达导致大面积断连。
五、为 mTLS 做准备：一张检查清单
在正式配置 mTLS 前，建议按以下清单核对证书体系是否就绪。以下参数为教学示例，实际部署时请替换为真实值。
| 检查项 | 示例值 / 要求 | 判断依据 |
|---|---|---|
| 根 CA 证书 | root-ca.crt，自签名，有效期 20 年 |
已导入 Broker 与客户端信任库 |
| 中间 CA 证书 | intermediate-ca.crt，由根 CA 签发 |
Broker 下发链中包含它 |
| 服务器证书 SAN | DNS:mqtt.example.com |
与客户端连接地址完全一致 |
| 客户端证书用途 | extendedKeyUsage = clientAuth |
Broker 校验通过，未被拒绝 |
| 证书链完整性 | 服务器证书 + 中间证书 | openssl s_client -showcerts 可见两级 |
| 吊销校验 | CRL 或 OCSP 至少启用一种 | 吊销后的证书无法建立连接 |
openssl verify -CAfile root-ca.crt -untrusted intermediate-ca.crt server.crt。若返回 OK，说明链可被正确构建；若报 unable to get local issuer certificate，通常是中间证书缺失或根证书未加入信任库。
理解以上构件后，后续配置 mTLS 时就能明确每一步在做什么：生成密钥对、签发证书、组装证书链、配置信任库、启用吊销校验。任何一步缺失或错位，都会在 TLS 握手阶段以具体的错误信息暴露出来，而掌握证书链和吊销机制正是定位这些错误的关键。