本月，Let's Encrypt 将开启新的基础设施以支持通过证书吊销列表吊销证书。尽管十多年来已在很大程度上被在线证书状态协议取代，但 CRL 正在通过最近的浏览器更新获得新的生命。通过为用户收集和汇总 CRL，浏览器正在使可靠的证书撤销成为现实，从而提高网络的安全性和隐私性。让我们来谈谈这个新基础设施的确切作用，以及它为什么重要。

撤销简史

当证书变得不可信任时（例如，因为其私钥被泄露），必须撤销该证书并公布该信息，以便将来没有人依赖它。然而，在 Web 公钥基础设施 (Web PKI) 的世界里，有一句老生常谈的格言：撤销已被破坏。在 Web PKI 的历史上，有两种主要机制用于声明不应再信任 TLS/SSL 证书：证书撤销列表 (CRL) 和在线证书状态协议 (OCSP)。不幸的是，两者都有很大的缺点。

CRL 基本上只是给定证书颁发机构 (CA) 颁发的所有已撤销证书的列表。这意味着它们通常非常大——很容易就是整部电影的大小。您的浏览器下载大量已撤销证书的巨大列表只是为了检查您正在访问的站点的单个证书是否已被撤销，这是低效的。这些缓慢的下载和检查导致网页加载缓慢，因此开发了 OCSP 作为替代方案。

OCSP 有点像“如果每个证书都有一个单独的 CRL 会怎么样”：当您想检查给定证书是否已被吊销时，您的浏览器可以通过联系 CA 的 OCSP 服务来检查该证书的状态。但是由于 OCSP 基础设施必须持续运行并且可能像任何其他 Web 服务一样遭受停机，因此大多数浏览器将完全没有响应视为等同于获得“未撤销”响应。这意味着攻击者可以通过阻止您对 OCSP 信息的所有请求来阻止您发现证书已被吊销。为了帮助减少 CA 的 OCSP 服务的负载，OCSP 响应有效并且可以缓存大约一周。但这意味着客户端不会非常频繁地检索更新，并且通常会在证书被撤销后的一周内继续信任它们。也许最糟糕的是：由于您的浏览器会为您访问的每个网站发出 OCSP 请求，因此恶意（或合法强制）的 CA 可能通过跟踪您请求 OCSP 的站点来跟踪您的浏览行为。

因此，现有的两种解决方案都无法真正发挥作用：CRL 效率低下，大多数浏览器都不检查它们，而 OCSP 又不可靠，大多数浏览器都不检查它。我们需要更好的东西。

浏览器汇总的 CRL

最近取得进展的一种可能的解决方案是专有的、特定于浏览器的 CRL 的想法。尽管不同的浏览器以不同的方式实现这一点（例如，Mozilla 将其称为 CRLite，而 Chrome 将其称为 CRLSets），但基本思想是相同的。

浏览器供应商集中下载 CRL，而不是让每个用户的浏览器在他们想要检查撤销时下载大型 CRL。他们将 CRL 处理成更小的格式，例如布隆过滤器，然后使用预先存在的快速更新机制将新的压缩对象推送到所有已安装的浏览器实例。例如，Firefox 每 6 小时推送一次更新。

这意味着浏览器可以提前下载撤销列表，保持页面加载速度快，并减轻普通 CRL 的最严重问题。它在本地进行撤销检查，推送的更新可以立即生效，而无需等待可能长达数天的 OCSP 缓存过期，从而防止 OCSP 出现所有最严重的问题。

由于这些浏览器汇总 CRL 的承诺，Apple 和 Mozilla 根程序都要求所有 CA 在 2022 年 10 月 1 日之前开始发布 CRL。具体来说，他们要求 CA 开始发布一个或多个 CRL，这些 CRL 共同涵盖所有证书由该 CA 发布，并且指向这些 CRL 的 URL 列表在通用 CA 数据库 (CCADB) 中公开。这将允许 Safari 和 Firefox 切换到使用浏览器汇总的 CRL 检查撤销。

我们的新基建

当 Let's Encrypt 成立时，我们明确决定只支持 OCSP，根本不生产 CRL。这是因为当时的根程序要求只规定了 OCSP，同时维护这两种撤销机制会增加错误可能导致合规事件的地方的数量。

当我们着手开发 CRL 基础架构时，我们知道我们需要构建规模，并以反映我们对效率和简单性的重视的方式进行构建。在过去的几个月里，我们开发了一些新的基础设施，使我们能够发布符合即将到来的要求的 CRL。每个组件都是轻量级的，专门用于完成一项任务并且做得很好，并且能够很好地扩展到我们当前的需求之外。

Let's Encrypt 目前每天都有超过 2 亿个活动证书。如果我们遇到需要同时撤销这些证书中的每一个的事件，则生成的 CRL 将超过 8 GB。为了使事情不那么笨重，我们将把我们的 CRL 分成 128 个分片，每个分片在最坏情况下达到 70 兆字节的最大值。我们使用一些精心构造的数学来确保——只要分片的数量不变——当重新发布 CRL 时，所有证书都将保留在它们的相同分片中，这样每个分片都可以被视为一个迷你 CRL 具有一致的范围。

根据我们颁发证书时遵循的相同最佳实践，我们所有的 CRL 将在由我们的颁发中间体签署之前检查是否符合 RFC 5280 和基本要求。尽管流行的 linting 库 zlint 尚不支持 linting CRL，但我们已经编写了自己的检查集合，并希望将来将它们上游到 zlint。这些检查将有助于防止合规事件并确保无缝的发行和更新周期。

作为开发这些新功能的一部分，我们还对 Go 标准库的 CRL 生成和解析实现进行了多项 改进。随着我们和 Go 社区的其他成员在未来更频繁地使用 CRL，我们期待做出更多改进。

尽管我们将生成涵盖我们颁发的所有证书的 CRL，但我们不会将这些 URL 包含在我们证书的 CRL 分发点扩展中。目前，根据基线要求，我们的证书将继续包含一个 OCSP URL，任何人都可以使用该 URL 来获取每个证书的吊销信息。我们新的 CRL URL 将仅在 CCADB 中公开，以便 Apple 和 Mozilla 根程序可以使用它们，而不会将它们暴露在来自互联网其他部分的潜在大量下载流量中。

撤销的未来

在真正修复 Web PKI 中的撤销之前还有很长的路要走。围绕 OCSP 的隐私问题只有在所有客户端都停止依赖它后才会得到缓解，我们仍然需要为非浏览器客户端开发可靠地检查撤销信息的好方法。

我们期待继续与 Web PKI 社区的其他成员合作，为每个人提供私密、可靠和高效的撤销检查。

如果您对我们开发更强大和私密的撤销机制的工作感到兴奋，您可以通过捐赠来支持我们，或者鼓励您的公司或组织赞助我们的工作。作为一个非营利项目，我们 100% 的资金来自社区和支持者的贡献，我们有赖于您的支持。