OCSP与CRL双模式切换改造实战 - 第1节
证书吊销到底是个啥？
说白了，证书吊销就是给一张证书贴上「作废」标签。你可能会问：证书不是都有有效期吗？到期自动失效不就行了？嗯，理论上没错，但现实中总有意外。
哪些场景必须走吊销？
- 私钥泄露 – 被黑客拿到私钥，证书就没法信任了。
- 域名/主体变更 – 原网站停止运营，证书却还在有效期内。
- CA 错误签发 – 比如 2018 年 Symantec 因违规签发被强制吊销。我在审计项目里见过一次 CA 把测试域名签成生产证书，吓得赶紧写了个脚本批量吊销。
- 密钥算法升级 – 从 SHA‑1 迁移到 SHA‑256 时，旧证书必须立即停用。
所以，吊销机制是 PKI 体系里兜底的「紧急刹车」。没有它，CA 一签就是死局。
CRL – 传统但靠谱的解
证书吊销列表（Certificate Revocation List），简称 CRL。它的思路很简单：
- CA 定期生成一个黑名单文件，里面列出所有已被吊销的证书序列号。
- 客户端（浏览器、VPN、服务器）下载这个文件，缓存起来。
- 每次验证证书时，先查一下黑名单里有没有这个序列号。
CRL 最大的优点是 离线可用。客户端下载一次，到期前都自己能验证。但缺点也明显：
| 项 | 说明 |
|---|---|
| 文件体积 | CA 签发量大时，CRL 可能上百 MB。我曾在一个政府项目里见过 200MB+ 的 CRL，客户端解压就卡几十秒。 |
| 更新延迟 | CRL 是按周期发布的，比如 24 小时刷新一次。如果私钥刚泄露，也要等到下一个周期才能列入黑名单。 |
| 分发压力 | 每次更新都有海量客户端去拉取，CDN 成本不低。 |
OCSP – 实时查询方案
在线证书状态协议（Online Certificate Status Protocol）就是来解决实时性问题的。它的逻辑像查户籍：
- 客户端拿着证书，向 OCSP 响应器（OCSP Responder）发送一条请求。
- 响应器查询后台数据库，立马返回「良好」「已吊销」或「未知」。
- 客户端只信这次查询的结果，不缓存长期数据。
好处是实时、轻量。但代价是你必须时刻在线。而且 OCSP 响应器如果挂了
下面是 CRL 和 OCSP 的核心差异对比，我建议你直接记这张表：
| 维度 | CRL | OCSP |
|---|---|---|
| 实时性 | 周期性更新（延迟）。 | 秒级实时。 |
| 网络依赖 | 离线可验证（缓存期内）。 | 每次都必须在线。 |
| 性能 | 文件大、解析慢。 | 请求/响应轻量。 |
| 单点风险 | 分发服务器压力。 | OCSP 响应器故障即不可用。 |
| 隐私 | 无隐私泄露。 | CA 能知道哪个客户端查了哪个证书。 |
证书状态的三元模型
RFC 5280 定义得很清楚：一张证书在任何时刻只能处于三种状态之一。
- good – 正常的，未被吊销。
- revoked – 已被吊销，不可再信。
- unknown – 无法确认状态。OCSP 查不到时返回这个，客户端应该自行决定是否信任。
你想想看，如果一个 OCSP 响应器返回 unknown，而客户端策略又是「默认不可信」，那就等于拒了所有合法证书。我在金融客户那里见过这种配置，结果大早上业务投诉说 VPN 连不上… 他们没调 OCSP 的 UnknownIsGood 选项。嗯，细节决定成败。
CRL 与 OCSP 的工作流程
下面这张图把两种模式画在一起，方便你理解它们在整个 PKI 体系中的位置：
为什么我们需要双模式切换？
CRL 和 OCSP 都有短板，你不能只依赖一个。我刚开始做 PKI 运维时，公司只用 CRL，结果有一次证书被吊销后，CRL 列表 24 小时没刷新，攻击者利用那个证书整了 6 个小时才被阻断。后来我们加了个 OCSP 作为第二道防线，但 OCSP 响应器每隔几个月就会因为负载高或证书问题宕机。最后你猜怎么着？我们干脆做了个 双模式自适应切换：
- 正常情况下优先走 OCSP，实时验证。
- OCSP 无响应或超时时，自动降级到 CRL 缓存。
- CRL 也过期了？那就用最笨的 fallback：直接拒绝，并触发告警。
双模式切换的核心就是 不让单点故障导致整个 PKI 趴窝。后面的章节我会带你一步步实现这套自动切换逻辑，包括状态机、超时策略、缓存刷新周期，以及如何用代码落地。