在正常情况下，Let's Encrypt 每天签发近 两百万张证书。然而，当我们思考互联网基本基础设施需要做好哪些准备时，我们不会考虑正常情况。我们希望能够尽可能做好准备，应对可能出现的各种困难情况。在一些最糟糕的情况下，我们可能需要在 24 小时内重新签发所有证书，以避免大范围的网络中断。这意味着我们必须准备好一天签发 2 亿张证书，这是任何公开信赖的证书颁发机构从未做过的事情。

我们最近完成了大部分工作和投资，以实现一天签发 2 亿张证书的目标，我们希望让大家了解其中所涉及的内容。所有这些都是由我们的 赞助商 和资助者实现的，其中包括来自 思科、泰雷兹 和 Fortinet 的重大硬件捐赠。

场景

安全和合规事件在我们行业中是不可避免的。我们当然会尽力将它们降至最低，但由于我们预计它们会发生，因此我们花了很多时间准备以最佳方式应对。

在 2020 年 2 月，影响我们合规性的一个漏洞导致我们需要撤销并替换 300 万张有效证书。这大约占所有有效证书的 2.6%。

如果这个漏洞影响了我们所有的证书怎么办？那将超过 1.5 亿张证书，覆盖超过 2.4 亿个域名。如果这是一个更严重的漏洞，要求我们在 24 小时内撤销并替换所有证书怎么办？这就是我们需要做好准备的最坏情况。

更糟糕的是，在事件发生期间，需要一些时间来评估问题并做出决定，因此我们将在 24 小时计时器开始后的一段时间内开始撤销和重新签发。这意味着一旦做出撤销和替换 1.5 亿张或更多证书的重大决定，我们实际上就只有更少的时间了。

基础设施改进

在审查了我们的系统后，我们确定了四个主要的瓶颈，会阻止我们在一天内替换 2 亿张证书。数据库性能、内部网络速度、加密签名模块 (HSM) 性能和带宽。

数据库性能

Let's Encrypt 有一个主要证书颁发机构数据库，它是我们提供服务的核心。它跟踪证书签发状态和相关的帐户。它是写入密集型，但也需要大量的读取操作。在任何给定时间，单个数据库服务器都是写入者，一些读取操作被定向到具有副本的相同机器。这种单一写入非集群策略有助于一致性并降低复杂性，但意味着写入和一些读取必须在单个机器的性能约束内运行。

我们上一代的数据库服务器配备了双 Intel Xeon E5-2650 v4 CPU，总共 24 个物理核心。它们具有 1TB 内存，以及 24 个 3.8TB SSD，通过 SATA 连接，采用 RAID 10 配置。这些服务器在日常签发过程中运行良好，但无法处理在一天内替换所有证书的工作。

我们已经用 新一代的数据库服务器 替换了它们，这些服务器来自戴尔，配备了双 AMD EPYC 7542 CPU，总共 64 个物理核心。这些机器拥有 2TB 的更快内存。更快的 CPU 和双倍的内存很棒，但这些机器真正有趣的地方在于 EPYC CPU 各自提供了 128 个 PCIe4 通道。这意味着我们可以安装 24 个 6.4TB NVME 驱动器，以实现强大的 I/O 性能。没有可行的 NVME 硬件 RAID，因此我们已切换到 ZFS，以提供我们需要的數據保護。

内部网络

Let's Encrypt 的基础设施最初是使用 1G 铜缆网络构建的。通过将多个连接捆绑在一起以实现 2G 性能，以及使用我们的交换机上提供的数量有限的 10G 端口，它一直很好地服务于我们，直到 2020 年。

到 2020 年，我们在内部移动的数据量已超出了 1G 铜缆网络的有效处理能力。一些正常操作的速度远不如我们希望的那么快（例如备份、副本），并且在事件发生期间，1G 网络可能会导致我们响应出现重大延迟。

我们最初考虑升级到 10G，但了解到升级到 25G 光纤的成本并不高很多。思科最终慷慨地捐赠了我们此次升级所需的大部分交换机和设备，并且在更换了许多服务器网卡后，Let's Encrypt 现在运行在 25G 光纤网络上！

有趣的故事 - 回到 2014 年，思科曾捐赠了非常不错的 10G 光纤交换机，用于构建最初的 Let's Encrypt 基础设施。但是，我们当时的机柜深度异常短，10G 交换机无法物理容纳。我们不得不将它们退回，换成物理尺寸更小的 1G 交换机。当时，1G 似乎已经足够了。我们现在已经搬到了深度标准的新机柜中！

HSM 性能

每个 Let's Encrypt 数据中心都有一对 Luna HSM，它们负责对所有证书及其 OCSP 响应进行签名。如果我们想撤销和重新签发 2 亿张证书，我们需要 Luna HSM 执行以下加密签名操作

  • 2 亿张 OCSP 响应签名，用于撤销
  • 2 亿张证书签名，用于替换证书
  • 2 亿张 OCSP 响应签名，用于新证书

这意味着我们需要在 24 小时或更短时间内执行 6 亿次加密签名，并需要一些性能开销来处理请求聚类。

我们必须假设在事件发生期间，我们可能只有一个数据中心在线，因此当我们考虑 HSM 性能时，我们考虑的是我们能够用一对 HSM 做些什么。我们之前的 HSM 每秒大约可以执行 1100 次签名操作，一对 HSM 则可以执行 2200 次。这意味着在 24 小时内可以执行 1.9008 亿次签名，以全负荷运行。这还不够。

为了达到我们的目标，泰雷兹慷慨地捐赠了新的 HSM，性能大约是原来的 10 倍 - 每秒大约可以执行 10000 次签名操作，一对 HSM 则可以执行 20000 次。这意味着我们现在可以在 24 小时内从单个数据中心执行 8.64 亿次签名操作。

带宽

签发证书本身并不特别占用带宽，但在事件发生期间，我们通常会使用更多带宽来进行系统恢复和分析。我们将在数据中心和云之间移动大量的日志和其他文件，用于分析和取证目的。我们可能需要同步大型数据库。我们创建副本和额外的备份。如果我们数据中心的连接速度很慢，就会减缓我们的响应速度。

在确定数据中心连接速度可能会显着增加我们的响应时间后，我们相应地增加了带宽。Fortinet 帮助提供了硬件，帮助我们保护和管理这些更高容量的连接。

API 扩展

为了替换所有这些证书，我们需要一种高效且自动化的方式通知 ACME 客户端它们应该执行提前续订。通常，ACME 客户端会在其证书有效期剩余三分之一时续订，否则不会联系我们的服务器。我们去年 发布了一个 ACME 的草案扩展，其中描述了一种方法，允许客户端定期轮询 ACME 服务器以了解提前续订事件。我们计划完善该草案，进行实施，并与客户端和大型集成商合作，使其在客户端方面得到实施。

支持 Let's Encrypt

我们依赖于来自我们用户和支持者社区的贡献，才能提供我们的服务。如果贵公司或组织希望 赞助 Let's Encrypt，请发送电子邮件至 sponsor@letsencrypt.org。我们恳请您在能力范围内 个人捐款。