PKI 基础知识：公钥基础设施概念与原理

大家好，我是这次课程的主讲。在做 PKI SDK 性能优化之前，我建议咱们先回到最基础的地方——把 PKI 到底是什么、它是怎么转起来的，彻底理一遍。

说实话，我见过不少开发伙伴，证书验签代码写得飞起，但问到根证书怎么来的、证书链怎么构建的，就开始含糊了。你想想看，如果连基础都吃不透，后面做高并发优化，出问题你都不知道从哪查。

什么是 PKI？简单说，就是“信任的骨架”

PKI，全称是 Public Key Infrastructure，也叫公钥基础设施。说白了，它不是什么具体的技术，而是一整套“谁信谁、怎么信、出了问题怎么追责”的规则加工具。

举个小例子。我早期在做一个企业文档签章系统时，用户在两台电脑之间互发加密文档。起初我们直接把公钥写在邮件里，结果有一天用户 A 收到一个声称来自 CEO 的文件，差点把公司机密签出去了。嗯，那时候我才意识到，没有 PKI，你根本不知道你手上的公钥到底是谁的。

PKI 的五大核心组件

别看 PKI 听起来复杂，它的骨架其实就五个东西。我习惯把它们分成“后台干活”的和“前端展示”的两拨。

• CA（证书颁发机构）—— 负责签发证书。它是整个信任链的源头，类似于“公安局出入境管理处”。
• RA（注册机构）—— 对申请者身份进行校验，但一般不发证书。它像个“前台接待员”，核实你是不是你。
• 证书库 —— 存放已签发证书和吊销列表（CRL）的地方。可以是 LDAP 目录，也可以是个数据库。
• 证书持有者 —— 拥有公私钥对，并且向 CA 申请了证书的实体。这个实体可以是人、服务器、甚至一个物联网设备。
• 验证方 —— 依赖证书来确认对方身份的应用程序或服务。比如浏览器、VPN 网关、代码签名工具。

这些组件之间怎么交互？我画了一张图，你看看就明白了。

证书是怎么签发的？

理解了组件，咱们看看整个签发流程长什么样。这块我建议你记牢，后面 SDK 优化中，证书解析和链构建是吞吐大户。

1. 生成密钥对。持有者本地生成一对 RSA 或 ECC 密钥。私钥自己保管，公钥准备提交。
2. 生成证书签名请求（CSR）。CSR 里包含公钥、组织名称、域名等信息，用私钥签名，证明你确实拥有对应的私钥。
3. 提交给 RA。RA 对 CSR 里的身份信息做线下或线上验证。我记得有个项目对接客户，他们把 CSR 里的 CN 填错了，RA 没发现直接通过，结果后期所有证书都得重签，麻烦得很。
4. CA 签发证书。CA 收到 RA 的通过结果后，用 CA 自己的私钥给公钥签名，生成符合 X.509 标准的证书。
5. 发布到证书库。同时 CA 把证书放到公共可查的位置，并提供 CRL 或 OCSP 查询入口。

证书链是什么？为什么它那么重要？

单个的证书，验证方没法直接信任。它得顺着证书里的“签发者”字段，一级一级往上找，直到找到一个自己预先信任的根证书。这根链条，就叫 证书链。

证书链一般分三级：

• 根 CA 证书—— 自签名的，是信任锚点。浏览器和操作系统里内置了一大堆。
• 中间 CA 证书—— 由根 CA 签发，用来签发终端证书。这样做的好处是，如果中间 CA 私钥泄露，只需要吊销中间证书，不用动根证书。
• 终端实体证书—— 发给最终用户或服务器的那一张。

信任模型：几种常见的玩法

PKI 世界里，信任不是铁板一块的。不同的信任模型决定了你 SDK 在验证时，需要哪些根证书、要不要走交叉认证。我整理了一张表，方便你对比。

信任模型	说明	适用场景	对 SDK 的影响
层次型（树状）	根 CA → 中间 CA → 终端证书 一条路走到底	企业内网、政府 PKI	链构建简单，但根证书是单点
网状型（交叉认证）	多个 CA 互相签发信任	大型跨机构互通	需要处理多路径，链构建复杂
桥接型	设立一个桥 CA，连接不同 PKI 域	异源系统集成	需要额外的桥 CA 证书，验证步骤增加

说实在的，大部分商业 PKI SDK 默认走的是层次型。但你要是做面向银行、政务的 SDK，网状和桥接就避不开了。那意味着你的证书验证模块，得支持多路径选择和循环检测。

一个小总结

这一章我们把 PKI 的概念、组件、证书签发流程和信任模型过了一遍。这些东西看着基础，但相信我，它们就是你后面做高并发优化的地基。