2014年4月，Heartbleed漏洞震惊全球。这个OpenSSL库中的缓冲区越界读取漏洞可能导致服务器私钥泄露，理论上需要立即撤销并重新签发所有受影响的证书。然而，马里兰大学的研究团队在三周后发现：超过73%的易受攻击证书未被重新签发，超过87%未被撤销。更令人担忧的是，撤销率在周末会显著下降——仿佛攻击者也会休息。

这不是个别管理员的疏忽，而是证书撤销机制系统性失败的缩影。当私钥泄露时，理论上网站管理员应该立即联系证书颁发机构（CA）吊销证书，浏览器在建立连接前应该检查证书是否已被吊销。但现实是，即使一个证书被正式吊销，你的浏览器很可能仍然会接受它。

一个看似简单的问题

理解证书撤销的困境，需要从TLS证书的本质说起。证书的核心目的是将一个域名绑定到一个公钥。当你访问example.com时，服务器出示一张证书，声称"example.com的公钥是X"。浏览器需要验证这个声明是否可信。

证书通常有数年的有效期，但很多情况可能导致证书在到期前就应该失效：私钥泄露、证书被错误签发、域名所有权变更等。这就是证书撤销机制存在的原因——它应该像信用卡被盗后立即挂失一样工作。

问题在于：如何让全球数十亿浏览器知道某张特定证书已被撤销？

CRL：第一个失败的尝试

最早的解决方案是证书撤销列表（Certificate Revocation List，CRL）。RFC 5280定义了CRL的标准格式：CA维护一个包含所有已撤销证书序列号的签名列表，浏览器定期下载这个列表进行本地检查。

CRL的问题显而易见。大型CA可能签发了数百万张证书，其中数万张可能已被撤销。CRL文件可能达到数MB甚至数十MB。每次建立TLS连接前都要下载这么大的文件显然不可行，因此浏览器会缓存CRL。但缓存意味着延迟——从证书被撤销到浏览器知道可能需要数天。

更关键的是可用性问题。如果浏览器在启动时尝试下载CRL但网络不通（比如用户刚开机还没连上WiFi），它该怎么做？拒绝加载任何HTTPS网站显然不可接受。

OCSP：一个看起来更好的方案

1999年，RFC 2560引入了在线证书状态协议（OCSP），试图解决CRL的效率问题。浏览器不再下载整个列表，而是向CA的OCSP服务器发送一个查询：这张证书是否有效？服务器返回一个签名的响应，说明证书状态（有效/已撤销/未知）。

这看起来优雅多了。每次查询只需要几百字节的流量，响应是实时的，浏览器不需要维护庞大的本地缓存。

但OCSP带来了三个新问题。

首先是隐私问题。 当你向CA查询"mail.google.com的证书是否有效"时，你实际上在告诉CA你正在访问Gmail。由于OCSP请求通常通过明文HTTP发送，网络路径上的任何观察者也能看到你在访问哪些网站。

其次是性能问题。 每次TLS握手都需要额外的OCSP请求。Mozilla的测量数据显示，OCSP请求会使TLS握手增加约100毫秒的中位数延迟。对于追求极致性能的现代Web，这是难以接受的代价。

最致命的是可用性问题。 如果OCSP服务器无响应，浏览器该怎么处理？

软失败：安全带在车祸时断裂

这是证书撤销困境的核心。当浏览器无法获取撤销信息时，有两种选择：

硬失败（Hard Fail）：拒绝连接，显示安全警告。这看起来更安全，但会带来严重的可用性问题。如果CA的OCSP服务器宕机，所有使用该CA证书的网站都无法访问。CA服务器将成为整个互联网的单点故障。DDoS攻击者也会将目标转向OCSP服务器，因为打垮它们就能让大量网站瘫痪。

软失败（Soft Fail）：继续连接，假设证书有效。这是主流浏览器的选择，但它带来了致命的安全漏洞。

Google工程师Adam Langley对此有一个精准的比喻：软失败撤销检查就像"车祸时会断裂的安全带"。你每天都系着它，感觉安全，但真正出事故的那一刻，它救不了你。

攻击场景非常简单：攻击者通过中间人攻击拦截用户流量，同时阻止所有OCSP/CRL请求。浏览器会因为无法获取撤销信息而软失败，愉快地接受已被吊销的证书。真正需要撤销检查的时刻，恰恰是它失效的时刻。

Chrome在2012年做出了一个激进的决定：完全停止对大多数证书进行在线撤销检查。Chrome安全团队的解释很直接：这些检查既慢又不可靠，而且不提供真正的安全保障。

浏览器厂商的分歧

面对同样的困境，不同浏览器选择了不同的路径。

Chrome的CRLSets：Chrome维护一个精选的撤销证书列表，通过浏览器更新机制推送给用户。这个列表大小严格限制在256KB以内，只包含"高价值"的撤销——主要是中间CA证书和重大安全事件涉及的证书。代价是覆盖率极低：CRLSets只覆盖约1%的已撤销证书。Chrome实际上放弃了检查大多数终端实体证书的撤销状态。

Firefox的OneCRL：Firefox采用类似的集中式列表，同样主要关注中间CA证书。但Firefox仍然默认进行OCSP查询，只是采用软失败策略。2020年，SSL.com的测试显示，只有在开启OCSP的情况下，Firefox才能正确识别被撤销的证书。

Safari的混合策略：Apple维护一个撤销证书列表，但当遇到列表中的证书时，Safari会进行实时OCSP检查确认。未在列表中的证书不会触发在线检查。

Edge：基于Chromium的新版Edge与Chrome行为一致，依赖CRLSets。

这种分歧导致了一个尴尬的现实：同一张被撤销的证书，在不同浏览器上可能有完全不同的命运。

OCSP Stapling：一个未被广泛采用的改进

OCSP Stapling试图解决OCSP的隐私和性能问题。服务器预先从CA获取OCSP响应，然后在TLS握手时"钉上"（staple）这个响应，浏览器不再需要单独向CA查询。

这解决了隐私问题（CA不知道你在访问哪个网站），也解决了性能问题（省去额外的网络请求）。Cloudflare的测量显示，可靠的OCSP Stapling可以使连接时间缩短多达30%。

但OCSP Stapling有一个关键缺陷：服务器可以选择不提供钉上的响应。如果攻击者获得了一张被撤销的证书，他们只需要不提供OCSP响应，浏览器就会软失败并接受证书。

OCSP Must-Staple试图解决这个问题。这是一项证书扩展，告诉浏览器"这张证书必须附带OCSP响应，否则拒绝连接"。这把软失败变成了硬失败，但前提是浏览器支持这个扩展。Firefox是少数强制执行Must-Staple的主流浏览器。

然而，Must-Staple的采用率极低。研究数据显示，只有不到1%的TLS证书包含这个扩展。2024年12月，Let’s Encrypt宣布将在2025年停止支持OCSP Must-Staple，因为"浏览器支持有限，且主流Web服务器的实现存在严重的停机风险"。

CRLite：Firefox的技术突破

2025年4月，Firefox 137版本正式启用了CRLite，这是证书撤销领域十年来最重要的技术突破。

CRLite的核心创新是使用Bloom Filter Cascade来压缩撤销信息。Bloom Filter是一种概率数据结构，可以用极小的空间表示一个集合，代价是存在一定的假阳性率（可能误判有效证书为已撤销）。CRLite通过多级Bloom Filter级联来处理假阳性，最终实现了一个既能高效查询又能保证精确性的系统。

数据对比令人印象深刻：

方案 每日带宽 更新频率 覆盖率
完整CRL下载 ~300 MB 不定 100%
Chrome CRLSets ~600 KB 每日 ~1%
Firefox CRLite ~300 KB 每12小时 100%

CRLite只需要完整CRL千分之一的带宽，却能覆盖所有已撤销证书。更重要的是，它不泄露任何隐私信息——所有查询都在本地进行，CA和Mozilla都无法知道你在访问哪些网站。

Firefox成为第一个实现"快速、隐私保护、全面覆盖"证书撤销检查的浏览器。Mozilla的研究团队在IEEE S&P 2025上发表了相关论文，开源了整个实现。

OCSP时代的终结

2024年12月，Let’s Encrypt宣布将在2025年结束OCSP支持，只保留CRL作为唯一的撤销信息分发机制。Google Trust Services紧随其后，宣布了类似的计划。

Let’s Encrypt给出的理由很明确：

  1. 隐私风险：OCSP请求泄露用户浏览历史，即使Let’s Encrypt声称不记录这些信息，也可能被法律强制要求收集。

  2. 运营复杂性：OCSP服务必须保持极高的可用性，否则要么造成大规模网站不可访问（硬失败），要么形同虚设（软失败）。

  3. CRL已经足够：配合证书有效期缩短，CRL的延迟问题可以接受。

这标志着Web PKI的一个重要转折点。OCSP曾是解决CRL问题的希望，但最终因为隐私和可用性的根本矛盾而被放弃。

短证书：撤销问题的终极解法？

如果证书撤销这么困难，为什么不缩短证书有效期，让撤销"自然过期"？

这正是行业的方向。CA/Browser Forum在2025年4月通过了SC-081v3提案，制定了证书有效期缩短的时间表：

  • 2026年3月15日：最长有效期降至200天
  • 2027年3月15日：最长有效期降至100天
  • 2029年3月15日：最长有效期降至47天

Let’s Encrypt已经支持6天有效期的短期证书。如果证书只有几天有效期，撤销就不再是紧迫问题——攻击者获得私钥后，证书很快就会过期。

但这带来了运营挑战。管理员需要更频繁地更新证书，自动化工具变得更加关键。Certbot 4.0已经支持Let’s Encrypt的短期证书自动续期。

还有什么没解决？

即使有了CRLite和短证书，证书撤销问题仍未完全解决。

跨平台差异：Firefox的CRLite是桌面版独占功能，移动端和其他平台仍然依赖传统方法。Chrome在移动端的行为也与桌面版不同。

非浏览器应用：VPN客户端、邮件服务器、物联网设备等非浏览器应用如何处理证书撤销？很多根本没有撤销检查机制。

中间人攻击的边界：CRLite需要定期更新，如果攻击者能长期拦截所有流量，理论上可以阻止用户获取最新的撤销信息。

证书透明度与撤销的断裂：证书透明度（CT）让所有证书签发行为公开可见，域主可以监控是否有未经授权的证书被签发。但发现伪造证书后，如何有效撤销仍然是问题。

现实建议

对于网站运营者，理解证书撤销的现状至关重要：

不要依赖撤销机制保护用户。如果你的私钥泄露，撤销证书是必要的，但不要指望它能立即阻止攻击。考虑使用证书固定（Certificate Pinning）或CAA记录增加额外保护层。

如果安全是首要考虑，考虑短期证书。Let’s Encrypt的6天证书或自动续期的DV证书可以最小化私钥泄露的影响窗口。

配置OCSP Stapling（如果你的CA仍支持）。虽然OCSP正在被淘汰，但在过渡期内，它仍然可以提供性能和隐私收益。

监控证书透明度日志。使用Facebook Certificate Transparency Monitoring或CertSpotter等服务，及时发现未经授权的证书签发。

证书撤销的故事是Web PKI设计哲学的缩影：安全性、隐私性、可用性和性能之间的权衡，很少有完美解。从CRL到OCSP，从CRLSets到CRLite，每一代方案都在尝试解决前一代的问题，同时引入新的约束。

Adam Langley在2014年的判断至今仍然成立：传统在线撤销检查是"无用的安全戏"。但Firefox的CRLite证明了，创新的数据结构和聪明的工程设计可以突破看似无解的困境。当证书有效期缩短到47天时，这场持续二十年的技术突围或许终于能看到终点。

参考来源：

  • Adam Langley, “Revocation checking and Chrome’s CRLSet” (ImperialViolet, 2014)
  • Scott Helme, “Revocation is broken” (scotthelme.co.uk, 2017)
  • Mozilla Hacks, “CRLite: Fast, private, and comprehensive certificate revocation checking in Firefox” (2025)
  • Let’s Encrypt, “Ending OCSP Support in 2025” (2024)
  • CACM, “Analysis of SSL Certificate Reissues and Revocations in the Wake of Heartbleed” (2018)
  • Cloudflare Blog, “High-reliability OCSP stapling and why it matters” (2017)
  • CA/Browser Forum, “Ballot SC081v3: Introduce Schedule of Reducing Validity” (2025)
  • RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  • RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol