3. 密码学基础（下）
上一节我们聊了非对称加密和哈希，算是把密码学的「零件」认全了。但光有零件可造不出车——你想想看，你拿到了 Bob 的公钥，怎么确定这公钥真的是 Bob 的？万一中间人把公钥换成了他自己的呢？
这就是 PKI 要解决的核心问题：如何在大规模、不可信的网络里，安全地分发和验证公钥。
3.1 公钥基础设施（PKI）——信任的骨架
PKI 不是某个具体的算法，而是一整套策略、流程、硬件、软件的组合。我习惯把它理解成「数字世界的身份证系统」。
一个完整的 PKI 体系包含以下几个核心角色：
| 角色 | 类比 | 核心职责 |
|---|---|---|
| 证书颁发机构（CA） | 公安局/出入境管理局 | 签发、吊销证书，是整个信任链的根 |
| 注册机构（RA） | 派出所/街道办 | 审核申请者身份的真实性，把审核结果交给 CA |
| 证书持有者 | 持证人 | 拥有自己的公私钥对，向别人出示证书证明身份 |
| 依赖方 | 查身份证的人 | 验证证书是否有效，决定是否信任对方 |
| 证书库/仓库 | 全国人口信息库 | 存储已签发证书和吊销列表（CRL） |
一句话总结 PKI 的价值：它把「你直接信任 Bob」这个一对一问题，转化成了「你信任 CA，CA 担保 Bob」这个可扩展的三方模型。
3.2 证书颁发机构（CA）——信任的源头
CA 是 PKI 里最核心的实体。它的工作说白了就两件：发证和收证。
3.2.1 CA 怎么签发证书？
流程大致是这样：
- 申请者生成密钥对：自己本地生成，私钥永远不离开本地。
- 申请者提交 CSR：Certificate Signing Request，里面包含公钥和身份信息。
- RA 审核身份：个人要验身份证，企业要验营业执照。我见过有些项目图省事跳过了这步，结果证书被冒领，教训很深刻。
- CA 签发证书：CA 用自己的私钥对申请者的公钥+身份信息做数字签名。
- 返回证书：申请者拿到 X.509 格式的证书文件。
一个小技巧：生产环境里，CA 的私钥一定要放在硬件安全模块（HSM）里。我曾经见过直接把 CA 私钥存文本文件里的操作……嗯，那项目后来被审计打了个不及格。
3.2.2 证书里到底有什么？
X.509 证书是最通用的格式。打开一个证书看看，里面字段不少，但核心就这几个：
| 字段 | 含义 | 我关注的点 |
|---|---|---|
| Subject | 证书持有者身份（CN、O、OU 等） | CN 必须和域名严格匹配 |
| Issuer | 签发该证书的 CA 身份 | 用来追溯上级 CA |
| Subject Public Key Info | 持有者的公钥和算法 | RSA 2048 起步，现在推荐 4096 |
| Validity | 生效和过期时间 | 过期证书是安全漏洞的重灾区 |
| Signature | CA 对证书内容的数字签名 | 验证证书完整性的关键 |
| Serial Number | CA 分配给证书的唯一编号 | 吊销时靠它定位 |
3.3 证书链——信任的传递
你想想看，如果全世界所有证书都直接由一个根 CA 签发，那根 CA 的私钥一旦泄露，整个互联网都得瘫痪。所以实际 PKI 用的是层级结构。
3.3.1 三层模型
最常见的结构是三层：
- 根 CA（Root CA）：自签名证书，是整个信任链的锚点。平时离线保存，极少使用。
- 中间 CA（Intermediate CA）：由根 CA 签发，负责实际签发终端证书。可以有多个层级。
- 终端证书（Leaf/End-entity Certificate）：发给网站、设备、用户的证书。
为什么要这么设计？说白了就是风险隔离。中间 CA 的私钥泄露了，根 CA 可以吊销它，重新签发一个，根 CA 本身不受影响。
注意：证书链的验证是自下而上的。从终端证书开始，逐级验证上一级证书的签名，直到找到本地信任的根证书。中间任何一环断了，证书就不可信。
3.3.2 证书链的 SVG 结构图
下面这张图展示了典型的证书链结构：
3.4 证书验证——信任链的检查
当浏览器访问 HTTPS 网站时，它背后做了一系列证书验证。我拆开来说：
3.4.1 验证步骤
- 证书有效期检查：当前时间是否在 Validity 范围内？过期直接报错。
- 域名匹配检查：证书的 CN 或 SAN 是否和访问的域名一致？
- 吊销状态检查：通过 CRL 或 OCSP 查询证书是否被吊销。
- 签名链验证：逐级验证签名，直到信任的根证书。
- 密钥用法检查：证书的 Key Usage 是否允许当前用途？
避坑指南：我曾经遇到过一个案例，证书链里中间 CA 的证书没配全，服务端只发了终端证书。结果 Android 设备能通过（因为它内置了中间 CA），但 iOS 设备死活不认。解决方案很简单：服务端配置证书链时，把中间 CA 证书一起发过去。
3.4.2 吊销机制
证书还没到期就被吊销，原因可能是私钥泄露、域名变更、员工离职。两种主流方式：
| 方式 | 原理 | 优缺点 |
|---|---|---|
| CRL（证书吊销列表） | CA 定期发布一个被吊销证书的列表 | 简单，但有延迟，列表会越来越大 |
| OCSP（在线证书状态协议） | 实时查询单个证书的状态 | 实时性好，但 CA 要扛住查询压力 |
| OCSP Stapling | 服务端自己缓存 OCSP 结果，发给客户端 | 减轻 CA 压力，保护用户隐私 |
3.5 实际项目中的 PKI 设计建议
做了这么多年安全架构，我总结了几条 PKI 落地的铁律：
- 根 CA 必须离线：物理隔离，只在签发中间 CA 时才通电。我见过把根 CA 放服务器上天天跑着的，那跟裸奔没区别。
- 中间 CA 按用途拆分：SSL 证书一个中间 CA，代码签名一个，邮件加密一个。一个泄露不影响其他。
- 证书有效期要短：以前证书有效期五年，现在行业趋势是 1 年甚至 90 天。短周期能降低吊销成本。
- 自动化证书管理：用 ACME 协议（比如 Let's Encrypt）自动续期。手动换证书太容易出错了。
- 监控证书过期：提前 30 天、7 天、1 天告警。证书过期导致的服务中断，我见过太多次了。
最后说一句：PKI 不是银弹。它解决的是「公钥属于谁」的问题，但解决不了「私钥是否被偷」的问题。私钥保护，那是另一门学问了。