究竟为何要吊销

一份证书承载一个过期日期，但有时它必须在那个日期到来之前被取消。私钥可能已泄露、证书可能被错误地颁发，或域名可能已易手。在所有这些情形中，证书在密码学上仍然有效、且仍处于其有效期窗口之内，然而依赖方却应停止信任它。吊销便是用以说出“即便此证书尚未过期，也无视它”的机制。难的部分，是把那条消息可靠地递送给世上的每一个客户端，而这结果成了 web 中最薄弱的一环。

CRL：所发布的封锁名单

最初的答案是证书吊销列表（Certificate Revocation List），与证书规约一同定义于 RFC 5280。一个 周期性地发布一份它已吊销的序列号的、经签名的列表，而证书可经由一个 Distribution Point 指向它。一个客户端下载该列表，并核查该证书的序列号是否出现于其上。

问题在于大小与新鲜度。一个繁忙的 CA 可累积出庞大的列表，所以在每一次连接上下载并解析一份 CRL 是不切实际的，而一份被缓存的列表在下一次发布之前都是陈旧的。CRL 仍被使用，越来越多地以浏览器递送给它们自己的、压缩且预处理过的形式，但作为一项按连接的核查，它们的伸缩性很差。

OCSP：就一份证书发问

在线证书状态协议（Online Certificate Status Protocol），RFC 6960，本意是修复大小问题，办法是让一个客户端就单独一份证书发问、而非下载整个列表。客户端把该证书的序列号发给一个 响应者，并取回一个经签名的“good”、“revoked”或“unknown”。

这是拿一个问题换来三个。它增添延迟，因为客户端如今在连接建立期间多做一次网络往返。它泄露隐私，因为该响应者得知用户正在访问哪些站点。而它制造一种可用性耦合：若响应者宕机，客户端必须要么使连接失败，要么——远为常见地——软失败（soft-fail）并照常进行、仿佛该证书是好的，而这悄然挫败了整个要点。

OCSP stapling 与 Must-Staple

stapling 通过让服务器取来一份新近的、经签名的 OCSP 响应并把它附于 TLS 握手（来自 RFC 6066 的 status_request 扩展），来处理延迟与隐私问题。客户端无须联系响应者便获得新鲜度。Must-Staple，RFC 7633，是一个证书扩展，言明“若一个 staple 缺失则拒绝我”，弥合那个软失败的缝隙，但它很少被部署，因为单单一次 stapling 的打嗝便会让该站点宕机。

那个令人不安的真相

横跨这些机制，那个反复出现的失败是软失败：当吊销信息不可得时，客户端压倒性地选择可用性而非安全，并接受该证书。这使吊销恰在它被需要之时成为一张不可靠的安全网。浏览器以它们自己的带外系统作出回应，把吊销数据推送给它们自己，但那些按连接的协议从未兑现其承诺。

现代的答案：让证书更早过期

若你无法可靠地取消一份证书，替代方案便是让它足够短寿命，以致取消鲜少要紧：一份被攻陷的证书在数天或数周内便自行过期。业界已恰恰承诺于此。CA/Browser Forum 的 Ballot SC-081v3，于 2025 年 4 月获批，把公开 TLS 证书的最长寿命分阶段降下：从 398 天降至 200 天（自 2026 年 3 月起）、100 天（2027 年 3 月）与 47 天（2029 年 3 月），而域名验证的复用期缩至 10 天。另外，自 2023 年起，该 Forum 已允许在 7 天内过期的短寿命证书完全跳过 CRL 与 OCSP 支持，而 Let's Encrypt 已开始颁发寿命以天计的证书。整个前提，便是一个足够短的寿命本身即是吊销。

这唯有靠自动化才行得通。每六或七周手工续订证书是难以为继的，这便是为何 协议（见签名请求一文）与证书生命周期工具已成为必不可少的基础设施、而非一种便利。请注意，这些规则适用于浏览器根程序中受公开信任的证书；一个私有的内部 PKI 自定其自己的策略。

当你检视一份证书时这意味着什么

当你解码一份证书，有效期窗口不再是一个一年一次的事后想法；它正在成为首要的吊销控制项。工具关于 notBefore、notAfter，以及该证书此刻是否有效的报告，越来越是关于它的、与安全最相关之物。吊销列表与响应者仍然存在，但行进的方向是清楚的：缩短寿命，使吊销的问题鲜少出现。