证书撤销机制：CRL、OCSP、RC/RC对比

证书撤销，说白了就是把已经失效的证书拉进黑名单。
你想想看，私钥泄露、员工离职、域名过期……这些场景下如果不及时撤销，攻击者就能拿着旧证书伪装合法身份。
我个人最早接触这个是在一个金融 PKI 项目里，当时被客户问了一句：
“证书撤销到底用哪套方案？CRL、OCSP 还是别的？”
好，今天咱们就把这三兄弟放在一起，掰开了讲。

CRL（证书撤销列表）——传统但可靠

CRL 是最早的撤销方案。CA 定期发布一个列表，里面写着被撤销证书的序列号和撤销时间。
客户端拿到这个列表后，自己比对一下，就知道某张证书是否失效。

• 优点：结构简单，不依赖实时网络查询，适合离线场景。
• 缺点：列表越积越大，下载耗时。我记得有一次项目里，根 CA 的 CRL 竟然膨胀到 20MB，客户端每次启动都要拉一遍，用户体验极差。
• 避坑指南：我曾经遇到过度依赖 CRL 的 HTTPS 握手，结果因为 CDN 节点未更新 CRL 缓存，导致合法证书被判为无效。后来我们在 CRL 分发点加了多层缓存和增量 CRL 机制，才解决问题。

OCSP（在线证书状态协议）——实时查询

OCSP 的思路是：别再下载整个黑名单了，你只告诉我“这张证书现在到底行不行”就行。
客户端发起一个 OCSP 请求（包含证书序列号），CA 的 OCSP 响应器返回“good / revoked / unknown”。

• 优点：实时性高，响应数据极小（通常 1KB 以内），适合高频验证场景。
• 缺点：每张证书都要单独查一次，隐私泄露（CA 知道你正在访问谁）；而且如果 OCSP 响应器挂了，整个验证都会卡死。
• 个人体验：在电商大促期间，我负责的 OCSP 响应器曾被瞬间打爆，导致全站 HTTPS 握手延迟飙升。后来我们加了本地缓存和降级策略——OCSP 失败时优先用上次缓存的 CRL 兜底。

RC/RC（依赖方控制的撤销检查）——混合之道

RC/RC 的全称我习惯叫“Relying Party Controlled Revocation Check”。
它既不完全依赖 CA 的列表，也不每次实时问服务器，而是由依赖方（比如浏览器、应用）自行控制检查的策略和缓存。

典型做法：

1. 本地维护一份高频更新的 CRL 子集（只包含最近 N 天撤销的证书）。
2. 遇到证书时，先查本地缓存；如果找不到，再走 OCSP 查询。
3. OCSP 成功后，将结果写入本地缓存，并设定过期时间。

好在哪里？你想想看，大部分证书在有效期内都不会被撤销，本地缓存命中率高达 99% 以上。
只有在极少数撤销发生时才会触发网络查询，既避免了 CRL 的臃肿，又减少了 OCSP 的实时依赖。

但也有代价：依赖方需要自己管理缓存的同步逻辑，如果缓存过期策略配置不当，可能引入安全窗口。

三种机制对比