1. PKI 基础概念：公钥基础设施的定义、核心组件与信任模型
聊 PKI 之前，我先问你一个问题：
你每天用 HTTPS 访问网站、用 SSH 登录服务器、用代码签名给软件打上数字指纹——这些动作背后，是谁在担保“你连接的那个对象确实是它自己”？
答案就是 PKI，公钥基础设施。
说白了，PKI 就是一套让数字世界能“验明正身”的体系。它不只是一个算法，也不只是一张证书，而是一整套策略、硬件、软件和流程的组合。我做了十几年 PKI 相关的工作，见过太多团队把 PKI 简单理解成“装个 CA 发证书”，结果上线后证书链断裂、CRL 没人更新、私钥泄露了都不知道——嗯，这些坑我们后面会一个个填。
1.1 什么是公钥基础设施
公钥基础设施（Public Key Infrastructure，PKI）的核心目标只有一个：在不可信的网络环境中，建立可信的身份与加密通道。
它依赖非对称加密技术，但又不只是加密。PKI 解决的是三个实际问题：
- 你是谁？——身份认证
- 你的数据有没有被改过？——完整性校验
- 这件事是不是你干的？——不可否认性
我记得有一次帮一家金融机构做设备证书体系改造，他们的网络设备之间通信全靠 IP 白名单和预共享密钥。结果某天一台交换机被攻破，攻击者直接用那台设备的 IP 伪装成核心路由器，把整个内网流量都劫持了。事后复盘，如果当时有 PKI 做双向认证，这种攻击根本不可能发生。
核心观点：PKI 不是“有了就行”，而是“用对了才行”。证书只是载体，信任才是灵魂。
1.2 PKI 的核心组件
一个完整的 PKI 体系，至少包含以下四个组件。我习惯把它们比作“发证机关 + 审核员 + 档案室 + 黑名单”。
1.2.1 证书颁发机构（CA）
CA 是整个 PKI 的信任锚点。它负责签发、吊销和管理数字证书。CA 自己有一张根证书，所有由它签发的证书，最终都能追溯到这张根证书上。
CA 分两种：
- 公共 CA：比如 DigiCert、Let's Encrypt，面向互联网，浏览器默认信任。
- 私有 CA：企业自建，只在内网使用，设备证书体系几乎都用这种。
我个人建议，在设备证书场景下，永远不要用公共 CA 签设备证书。为什么？设备数量动辄上万，证书吊销、续期、策略调整都需要自主控制权。交给公共 CA，你连 CRL 分发周期都管不了。
1.2.2 注册机构（RA）
RA 是 CA 的前置审核模块。它不直接签发证书，而是负责：
- 验证申请者的身份
- 检查申请者是否具备获取证书的资质
- 将审核通过的信息转发给 CA
我在项目中遇到过一种情况：某团队直接让 CA 对外暴露注册接口，结果被批量恶意申请证书，CA 性能被打满，整个 PKI 系统瘫痪了三天。后来我们加了 RA 层，把审核和签发分离，问题才解决。
实战建议：RA 和 CA 最好物理或逻辑隔离。RA 可以放在业务网络，CA 必须放在安全区，甚至离线。
1.2.3 证书库
证书库是存放已签发证书和证书吊销列表（CRL）的地方。它通常基于 LDAP 目录服务或 HTTP 服务器实现。
证书库需要满足两个要求：
- 高可用：设备验证证书时，如果访问不到证书库，可能导致认证失败。
- 一致性：CRL 必须及时更新，否则已吊销的证书可能被继续使用。
我曾经踩过一个坑：某项目的 CRL 更新周期设置成 7 天，结果一台被吊销证书的设备在 6 天内依然能正常接入网络。从那以后，我对 CRL 的更新频率就特别敏感——设备证书场景下，CRL 更新周期建议不超过 24 小时，关键系统甚至要做实时 OCSP。
1.2.4 证书吊销机制（CRL / OCSP）
证书不是永久的。当设备报废、私钥泄露或人员离职时，证书必须被吊销。两种主流方式：
| 机制 | 原理 | 适用场景 |
|---|---|---|
| CRL | CA 定期发布吊销列表，客户端下载后比对 | 离线或低实时性场景 |
| OCSP | 客户端实时向 OCSP 响应器查询证书状态 | 高实时性、在线场景 |
注意：OCSP 虽然实时性好，但引入了额外的网络依赖。如果 OCSP 响应器宕机，客户端的行为取决于实现——有的会放行（soft-fail），有的会拒绝（hard-fail）。设备证书场景下，我建议用 OCSP stapling 或 CRL + OCSP 双通道兜底。
1.3 信任模型
信任模型决定了“谁可以信任谁”。不同的场景需要不同的模型，选错了，整个 PKI 体系就是空中楼阁。
1.3.1 严格层次模型
这是最常见的模型。一个根 CA 在最顶层，下面挂载二级 CA、三级 CA，形成树状结构。每个下级 CA 的证书都由上级 CA 签发。
优点：路径清晰，管理简单。
缺点：根 CA 一旦被攻破，整个体系崩塌。
我习惯在设备证书体系中使用这种模型，但根 CA 必须离线，二级 CA 用于日常签发。这样即使二级 CA 出问题，根 CA 还在，可以重新签发。
1.3.2 网状信任模型
多个 CA 互相交叉签发，形成网状结构。常见于联盟或跨组织场景。
优点：灵活性高，没有单点故障。
缺点：证书路径复杂，验证性能差。
说实话，我不推荐在设备证书体系里用网状模型。设备端的计算资源有限，证书链验证太复杂会拖垮性能。
1.3.3 桥接信任模型
用一个“桥 CA”连接多个独立的 PKI 体系。桥 CA 本身不签发终端证书，只做信任锚点的转换。
这种模型在大型企业合并或政府跨部门互信时很常见。我在一个智慧城市项目中用过桥接模型，把公安、交通、医疗三个独立的 PKI 体系打通，桥 CA 只做策略映射，不参与具体证书签发。
选型建议：设备证书体系首选严格层次模型。如果涉及跨组织互信，考虑桥接模型。网状模型尽量避开。
1.4 PKI 核心逻辑框架图
下面这张图展示了 PKI 的核心组件和信任关系。你可以把它当作本章的知识地图。
1.5 本章小结
PKI 不是一套软件，而是一套信任体系。它的核心组件——CA、RA、证书库、吊销机制——各司其职，缺一不可。信任模型决定了这个体系的骨架，选错了后面很难改。
我个人经验是：设备证书体系，从根 CA 离线开始设计。先把信任锚点保护好，再考虑签发策略、CRL 周期、OCSP 高可用这些细节。基础打牢了，后面 29 章的内容才能落地。
一句话记住本章：PKI = 可信的根 + 规范的流程 + 及时的吊销。少一个，都不叫完整的 PKI。