PKI 基础：掌握公钥基础设施的核心概念
聊 PKI 之前，我先讲个真实经历。几年前我接手一个安全审计项目，发现客户内部所有 HTTPS 证书都配成了自签名。问运维为什么，他说“反正都能用”。结果呢？中间人攻击一打就穿，裸奔了半年。说白了，没有一套可信的骨架，加密只是心理安慰。这一章我就带你理清 PKI 的骨架——CA、证书链、信任模型。搞懂了这些，OCSP 才能落地。
什么是 PKI？
公钥基础设施（PKI）不是某个具体产品，而是一套规则、流程和组件的集合。它的核心目标就两件事：绑定公钥与身份，以及提供可信的密钥管理。想象一下你拿到一张身份证，上面有你的照片、姓名、发证机关。PKI 的证书就是数字世界的身份证，发证机关就是 CA（证书颁发机构）。
PKI 包含这几个关键角色：
- CA（Certificate Authority）——颁发和撤销证书的机构，PKI 的“权威”所在。
- RA（Registration Authority）——审核申请者身份的中间角色，帮 CA 分担验证工作。
- 证书库——存储已颁发证书和 CRL（证书吊销列表）的公共仓库，通常通过 LDAP 或 HTTP 访问。
- 终端实体——持有证书并使用它进行加密或签名的设备/用户。
一句话总结：PKI 用非对称加密 + 数字证书 + CA 层级，把不可信的互联网通信变成可审计、可追溯的信任关系。我在做金融行业项目时，监管明确要求所有交易网关必须使用由受信任根 CA 签发的证书，否则直接判定为不合规。
证书颁发机构（CA）——谁说了算
CA 就是证书的“出生证明”签发处。它分两类：公共 CA（如 DigiCert、Let's Encrypt）和私有 CA（企业内部自建）。公共 CA 的根证书预装在操作系统和浏览器里，所以全世界都认；私有 CA 只能在内部网络中传播信任。
CA 的核心操作有四个：
- 身份验证——申请者提交 CSR（证书签名请求），CA 验证其是否拥有对应私钥，以及申请者是否对域名/组织有控制权。
- 签发证书——验证通过后，CA 用自己私钥对证书主体信息签名，生成 X.509 证书。
- 维护证书状态——包括 CRL 发布和 OCSP 响应（这正是我们课程的重头戏）。
- 证书撤销——私钥泄露或人事变动时，CA 将证书序列号加入 CRL 或更新 OCSP 状态。
| 维度 | 公共 CA | 私有 CA |
|---|---|---|
| 信任范围 | 全球（内置根证书） | 组织内部 |
| 申请成本 | 按年付费（或免费如 Let's Encrypt） | 仅运维成本 |
| 灵活性 | 受 CA/B 基线要求约束 | 完全自定义策略 |
| 撤销粒度 | 依赖 CRL/OCSP，延迟可能较大 | 可以实时推送吊销列表 |
我个人习惯在生产环境使用公共 CA 签发的证书对外服务，内部管理工具则跑私有 CA。既省钱又可控，不矛盾。
证书链——信任的传递链
你不可能让每个设备都内置所有 CA 的公钥，太笨重。所以现实世界用证书链（Certificate Chain）来传递信任。一条典型的链分三层：
- 根 CA 证书——自签名，信任锚点。浏览器内置了约 150 个根证书。
- 中间 CA 证书——由根 CA 签发，负责给终端实体签发证书。中间层可以有多级。
- 终端实体证书——你的服务器或客户端证书。
验证过程就像剥洋葱：从终端证书开始，用上层 CA 公钥验证它的签名，然后上层再用上上层验证，直到碰到受信任的根证书。这根链条上任何一环出问题（过期、撤销、签名不匹配），整个信任就断了。
我曾经踩过一个坑：部署 HTTPS 时只上传了服务器证书，没附带中间证书。结果 Android 设备报错“证书链不完整”，因为 Android 的密钥库没有预装那张中间 CA。解决方案很简单——把中间证书和服务器证书拼接成一个 .pem 文件一起部署。
⚠️ 重要提醒：证书链长度不要超过 6 层。太长的链会导致 TLS 握手时证书过大、验证时间变长，甚至被某些客户端拒绝。我曾经见过一套弱智 CA 体系，证书链竟然有 8 层，结果用户访问页面要多等 3 秒才显示锁图标。后来被安全团队强制整改。
信任模型——你相信谁
信任模型定义了谁可以签发谁的证书以及如何判断一个证书是否可信。常见的有三种：
1. 层次信任模型（Hierarchical）
最经典的模型。一个根 CA 位于顶端，下面挂多个子 CA，子 CA 再挂孙 CA，形成树状结构。特点：
- 信任方向单一（从上到下）。
- 根 CA 一旦泄露，整棵树完蛋。所以根 CA 通常离线存储，只在必要时开机。
- 适用场景：企业内网、政府 PKI 体系。
2. 网状信任模型（Mesh / Web of Trust）
每个 CA 都可以交叉认证其他 CA，形成一张网。PGP 和某些区块链场景用得多。特点：
- 去中心化，没有单点故障。
- 信任路径复杂，验证效率低。你想想看，两个节点之间的信任路径可能有几十条，选哪条？
- 实用中较少用于通用 SSL/TLS。
3. 桥接信任模型（Bridge CA）
专门为了解决不同 PKI 体系之间的互认问题而生。一个桥接 CA 作为中间人，连接两个原本独立的层次 PKI。举个例子：美国联邦政府 PKI 和国防部 PKI 之间就是通过桥接 CA 实现互信的。我参与过几个政务系统对接项目，用的就是这种模型。
| 模型 | 信任锚点 | 扩展性 | 撤销复杂度 |
|---|---|---|---|
| 层次 | 根 CA | 中等 | 简单（逐级查询） |
| 网状 | 多个自签名锚点 | 差 | 高（路径发现复杂） |
| 桥接 | 桥 CA | 好 | 中等（需跨域查询） |
💡 实战建议：多数企业选层次模型就够了。如果你需要和外部组织交互，而且双方 PKI 不一样，考虑部署一个桥接 CA 或使用公共 CA 签名的证书做“外交证书”。我在做跨境支付平台时，对方要求必须使用他们的根证书签发的客户端证书，我们就在边界网关做了双向认证+桥接策略，避免了重构内部 CA。
X.509 证书结构——你该看懂哪些字段
虽然本章不要求你记住所有字段，但我说几个和 OCSP 强相关的：
- 序列号 (Serial Number)——证书唯一标识，OCSP 请求里一定会携带这个字段。
- 颁发者 (Issuer)——签发此证书的 CA 的 DN（可分辨名称）。OCSP 响应需要确认 issuer 是否可信。
- 有效期 (Validity)——大部分 OCSP 撤销检查都会连带验证证书是否过期，过期证书直接判定无效。
- 扩展域：Authority Information Access (AIA)——这个扩展里藏着 OCSP 响应器 URL！没有它，客户端怎么找到 OCSP 服务？我在排查过一个莫名其妙的问题，证书的 AIA 字段竟然写了个内网 IP，公网客户端访问不到，导致 OCSP 查询超时回退到 CRL。——嗯，这个坑后面章节会详细讲。
📌 小技巧：可以用 openssl x509 -in cert.pem -text -noout 直接查证书的 AIA 字段。我每次部署前都会跑一遍这个命令，确保 OCSP 地址可达。