PKI基础概念：公钥基础设施
说实话，很多人一上来就问我：“PKI 到底是什么？”
我通常这么回答——PKI 就是一套让互联网世界互相信任的规矩和工具。你想想看，没有 PKI，你怎么证明你访问的银行网站是真的？你怎么知道下载的软件没被篡改？
我把 PKI 理解成“数字世界的身份认证系统 + 加密传输管道”。它解决的是三个核心问题：
- 你是谁？（身份认证）
- 消息有没有被改过？（完整性校验）
- 消息只有指定的人能看？（加密传输）
我在项目实施前，经常先给团队讲清楚这个底层逻辑。只有把“为什么要建 PKI”想明白了，后面的上线和测试才不会跑偏。
1.1 公钥基础设施的定义
公钥基础设施，英文叫 Public Key Infrastructure，简称 PKI。它是一套基于非对称加密技术的软硬件集合、策略和流程的总称。
说白了，PKI 就是一套完整的“发证、用证、管证”的体系。它利用公钥和私钥这对密钥对，完成身份认证、数据加密和数字签名。
核心公式：
- 用私钥签名，用公钥验签 → 证明“你”是你
- 用公钥加密，用私钥解密 → 只有“你”能看到
我在项目中见过太多人把 PKI 和 SSL/TLS 划等号，这是不对的。PKI 是骨架，SSL/TLS 只是它的一种应用场景，就像你家的电路系统和电灯的关系一样。
1.2 PKI 的组成要素
PKI 并不是一个“东西”，而是一个体系。它要正常运行，必须包含以下四大核心要素：
1.2.1 证书颁发机构（CA）
CA 是 PKI 的核心、也是整个信任链的源头。它的职责就是签发、吊销和管理数字证书。
我个人习惯把 CA 比作“派出所”——它负责给人（或设备）办身份证。
- 根CA： 自签名的信源，整个信任链的“老祖宗”。
- 子CA / 中间CA： 受根CA委托，签发最终用户证书，降低根CA直接暴露的风险。
1.2.2 注册机构（RA）
RA 是 CA 的“前端”或“业务窗口”。它负责审核申请人的身份信息，确认申请人确实有资格获得证书。
我曾经遇到过一个客户，他们把 RA 和 CA 部署在同一台物理服务器上，美其名曰“节省资源”。结果？RA 服务器的安全漏洞直接导致了 CA 的私钥泄露。后来我把设计方案改成了RA 和 CA 必须物理或逻辑隔离，这算是一个血的教训。
1.2.3 证书存储库与吊销机制
光有证书还不够，得让人家能查到这张证有没有过期，有没有被吊销。
- LDAP / HTTP 证书库： 提供证书查询和下载。
- CRL（证书吊销列表）： 由 CA 定期发布被吊销的证书序列号清单。
- OCSP（在线证书状态协议）： 实时查询某张证书是否有效。我建议线上系统优先用 OCSP，因为 CRL 下载有延迟。
1.2.4 最终用户与终端实体
一切的证书，最终都是为了服务终端实体。比如：
- 用户： 使用个人证书进行邮件签名、登录。
- 服务器： 使用 SSL 证书实现 HTTPS。
- 代码： 使用代码签名证书验证软件发布者。
| 组成要素 | 核心职责 | 我遇到过的坑 |
|---|---|---|
| CA | 签发与管理证书 | 私钥保护是命门，HSM 别省 |
| RA | 身份审核与注册 | 和CA必须隔离部署 |
| 证书库/吊销 | 证书存储与状态查询 | OCSP响应端必须高可用，否则业务会卡死 |
| 终端实体 | 最终使用证书的用户/设备 | 私钥到处复制是合规大忌 |
1.3 信任模型
有了 CA，有了证书，那一个问题来了：我凭什么相信你的根是根？
这就引出了 PKI 的信任模型。它定义了信任如何在不同的实体之间传递和验证。我个人把信任模型归结为四种，你可以根据组织规模和业务需求来选。
1.3.1 严格层次结构模型
这是最经典的模型，也是互联网 HTTPS 在用的模型。一张“根CA → 中间CA → 终端实体”的树状信任链。上层的 CA 给下层的 CA 或用户签发证书。
优点： 结构清晰、路径简单、管理方便。
缺点： 根CA一旦被攻破，整个树下的所有证书都不安全。
1.3.2 分布式信任模型
也叫“桥CA模型”或“网状模型”。它适用于两个独立PKI体系需要互信的场景。比如公司A和公司B各自有自己的根CA，现在需要业务互通。
这时候会出现一个“桥CA”，它同时被两个根CA信任，从而在两个信任域之间搭起一座“桥”。
- 我遇到过一家跨国集团，整个欧洲分部用一个PKI，亚太分部用另一个PKI。我们加了一个桥CA搞定跨域认证，比推倒重建省力90%。
1.3.3 用户中心模型
这种模型比较极端——用户自己就是自己的CA。典型代表是 PGP（Pretty Good Privacy）。用户自己生成密钥对，自己签发证书，互相签名建立信任。
说实话，这种模型在大型企业里不太适用，因为没有中心化的控制和审计。但在一些高度强调个人隐私的场景（比如加密通信）中还是有用的。
1.3.4 信任链验证流程
不管你用哪种模型，最终验证的时候走的逻辑都是一样的：
- 从终端实体的证书开始，获取其“颁发者”信息。
- 找到颁发者（中间CA）的证书，验证终端证书上的签名。
- 重复步骤2，直到找到根CA（自签名）证书。
- 验证根CA证书是否在本地的“受信任的根证书颁发机构”列表中。
- 检查证书是否在CRL中或被OCSP标记为吊销。
1.3.5 我心中的“非链式信任”
你可能会想：“如果中间CA的证书也没有被信任，怎么办？”
这就是为什么根CA的证书必须预埋在操作系统或浏览器里。这也是为什么给用户签发证书时，要一并下发完整的证书链文件（Chain Certificate）。如果你只发了终端证书，忘了带上中间CA，服务端会找不到完整的信任路径，客户端也会报“不受信任”的错。
我记得去年排查一起排错，测试环境怎么都建立不了TLS握手。最后发现工程师只部署了服务器证书，没把中间CA串起来。加上中间CA后，一切正常。嗯，这种细节在上线前测试时最容易漏。
openssl verify -CAfile root-ca.crt -untrusted intermediate.crt server.crt