Let's Encrypt 改善了我们管理 OCSP 响应的方式

Let's Encrypt 通过部署 Redis 并按需生成响应而不是预生成响应，改进了我们管理在线证书状态协议 (OCSP) 响应的方式，使我们比以往更加可靠。

关于 OCSP 响应

OCSP 用于通信 TLS 证书的吊销状态。当 ACME 代理签署吊销证书的请求时，我们的 Let's Encrypt 证书颁发机构 (CA) 会验证请求是否已获授权，如果已获授权，我们会开始发布该证书的“吊销”OCSP 响应。每次依赖方（如浏览器）访问带有 Let's Encrypt 证书的域时，它们都可以请求有关证书是否已被吊销的信息，我们会提供包含“正常”或“吊销”的回复，由我们的 CA 签名，我们称之为 OCSP 响应。

巨大的 OCSP 响应负载：每秒 100,000 个

Let's Encrypt 目前为超过 3 亿个域提供服务，这意味着我们接收大量的证书吊销状态请求 - 每秒处理约 100,000 个 OCSP 响应！

通常，我们 98-99% 的 OCSP 响应由我们的内容交付网络 (CDN) 处理。但有时我们的 CDN 会出现问题，导致 Let's Encrypt 需要直接接受更多请求。从历史上看，我们最多可以有效地响应我们 OCSP 响应流量的 6%。如果我们需要接受比这高得多的流量，我们的一些系统可能会开始花费太长时间返回结果，返回大量错误，甚至停止接受新请求。对我们或互联网来说，这不是一个理想的情况。

当我们的 CDN 之一出现问题时，我们无法提供 OCSP 响应，这会导致用户浏览速度变慢或无法连接到网站 - 或者更糟糕的是，互联网用户无意中访问了已吊销证书的域。浏览器对无响应的 OCSP 的反应不同，但有一点很清楚，我们的系统需要更好地处理这些情况。

提高可靠性

在 2022 年的大部分时间里，我们的工程师都在努力工作，极大地提高了我们独立提供 OCSP 响应的能力。我们通过部署 Redis 作为内存中缓存层来实现这一点，该层有助于通过吸收流量峰值来保护我们的数据库，无论是由于 CDN 问题还是我们自己的操作，例如 CDN 缓存清除。

设计上的转变

我们的团队开发了一种系统架构设计，用于组织/更改使 Redis 能够信赖地提供我们的 OCSP 响应所需的所有相互关联的系统。在开发这种设计的热潮中，我们的工程师发现了一种我们可以更多地依赖的资源，它可以简化整体架构，并且仍然可以实现令人难以置信的可靠性提升。与其定期预先签名 OCSP 状态响应，将结果存储在关系数据库中，并要求 Redis 保持副本，我们可以在我们的数据库中保留简单但权威的证书状态信息。然后，我们可以利用来自我们的 HSM 的快速、并发签名功能来实时签名新的 OCSP 响应，将其缓存到 Redis 中，并将其返回给请求者。得益于此，关系数据库的负担大大减轻（尤其是总表写入和写入冲突），速度令人印象深刻，Redis 并没有保存任何不能（非常非常快地）重新生成的任何内容。

测试我们的系统

第一次测试是直接接受 1/16 的请求，方法是删除我们 CDN 缓存的一部分。在最初的测试中，我们每秒处理约 12,500 个请求。随后的测试逐步提高到 1/8 的 CDN 缓存删除，然后是 1/4，然后是 1/2，最后是 100% 的缓存删除。随着测试负载的每次提高，我们能够监控并收集有关我们的部署如何处理流量的见解。在最后 100% 请求的测试中，我们的系统保持响应。这意味着，如果我们遇到需要接受更多 OCSP 响应的峰值，我们有能力处理它们，从而大大降低了对互联网用户的风险。

支持 Let's Encrypt