2020 年 9 月 3 日星期四，Let's Encrypt 发布了六个新证书：一个根证书，四个中间证书和一个交叉签名证书。这些新证书是我们更大计划的一部分，旨在通过使 ECDSA 终端实体证书广泛可用以及使证书更小来提高网络上的隐私。

鉴于我们每天签发 150 万个证书，是什么让这些证书如此特别？我们为什么发布它们？我们如何发布它们？让我们回答这些问题，并在此过程中了解证书颁发机构的思考和工作方式。

背景故事

每个公开可信的证书颁发机构（如 Let's Encrypt）都至少有一个根证书，该证书已包含在各种浏览器和操作系统供应商（例如 Mozilla，Google）的可信根存储区中。这就是允许接收网站证书的用户确认证书是由其浏览器信任的组织签发的。但是，根证书由于其广泛的信任和较长的有效期，必须将其相应的私钥仔细保护并脱机存储，因此不能始终用于签名。因此，每个证书颁发机构 (CA) 还会有一些数量的“中间证书”，这些证书能够颁发其他证书，但不是根证书，它们用于日常颁发。

在过去 五年中，Let's Encrypt 只有一个根证书：ISRG Root X1，它具有 4096 位 RSA 密钥，有效期至 2035 年。

在同一时期，我们拥有四个中间证书：Let's Encrypt Authorities X1、X2、X3 和 X4。前两个是在 Let's Encrypt 于 2015 年开始运营时签发的，有效期为 5 年。后两个是在大约一年后的 2016 年签发的，同样有效期为 5 年，将于明年这个时候到期。所有这些中间证书都使用 2048 位 RSA 密钥。此外，所有这些中间证书都由 IdenTrust 的 DST Root CA X3 交叉签名，另一个由不同的证书颁发机构控制的根证书，该证书受到大多数根存储区的信任。

最后，我们还有 ISRG Root OCSP X1 证书。这个证书有点不同 - 它不颁发任何证书。相反，它签署了在线证书状态协议 (OCSP) 响应，表明中间证书未被吊销。这一点很重要，因为唯一能够签署此类声明的是我们的根证书本身，如上所述，根证书需要保持脱机状态并安全保存。

Let’s Encrypt’s hierarchy as of August 2020

新证书

首先，我们发布了两个新的 2048 位 RSA 中间证书，我们称之为 R3 和 R4。这两个证书都是由 ISRG Root X1 签发的，有效期为 5 年。它们也将由 IdenTrust 交叉签名。它们基本上是我们当前 X3 和 X4 的直接替代品，它们将在一年内到期。我们预计将在今年晚些时候将我们的主要签发管道切换到使用 R3，这不会对签发或续订产生任何实际影响。

其他新证书更有趣。首先，我们有新的 ISRG Root X2，它使用 ECDSA P-384 密钥而不是 RSA，有效期至 2040 年。从该证书签发，我们拥有两个新的中间证书，E1 和 E2，它们也都是 ECDSA，有效期为 5 年。

值得注意的是，这些 ECDSA 中间证书没有由 IdenTrust 的 DST Root CA X3 交叉签名。相反，ISRG Root X2 本身由 我们现有的 ISRG Root X1 交叉签名。敏锐的观察者可能还会注意到，我们尚未从 ISRG Root X2 签发 OCSP 签名证书。

Let’s Encrypt’s hierarchy as of September 2020

现在我们已经了解了技术细节，让我们深入了解新层次结构的原因。

我们为什么要发布 ECDSA 根证书和中间证书

有很多关于 ECDSA 好处的 其他文章（相同安全级别下密钥尺寸更小；相应地加密、解密、签名和验证操作更快；等等）。但对我们来说，最大的好处来自它们更小的证书尺寸。

通过 https:// 到远程域的每个连接都需要进行 TLS 握手。每个 TLS 握手都需要服务器提供其证书。验证该证书需要证书链（所有中间证书的列表，但不包括可信根证书），通常也由服务器提供。这意味着每个连接 - 以及包含广告和跟踪像素的页面可能具有数十个或数百个连接 - 最终会传输大量证书数据。每个证书都包含它自己的公钥以及其颁发者提供的签名。

虽然 2048 位 RSA 公钥大约为 256 字节长，但 ECDSA P-384 公钥仅为大约 48 字节。同样，RSA 签名将是另外 256 字节，而 ECDSA 签名将仅为 96 字节。考虑到一些额外的开销，每个证书可以节省近 400 字节。将此乘以链中的证书数量，以及您每天获得的连接数量，带宽节省就会迅速增加。

这些节省对我们的用户来说是一种公共利益 - 他们可能是带宽可能成为每月重要成本的网站 - 以及最终用户，他们可能具有有限的或计量的连接。将隐私带到整个网络不仅仅意味着提供证书，还意味着使其更高效。

顺便说一句：由于我们关心证书的大小，因此我们在新证书中也采取了一些其他措施来节省字节。我们将它们的主题通用名从“Let's Encrypt Authority X3”简化为“R3”，依靠以前冗余的组织名称字段提供“Let's Encrypt”一词。我们缩短了它们的授权信息访问颁发者和 CRL 分发点 URL，并且完全删除了它们的 CPS 和 OCSP URL。所有这些加起来可以节省另外大约 120 字节，而不会对证书中有用信息进行实质性更改。

我们为什么要交叉签名 ECDSA 根证书

交叉签名是一个重要的步骤，弥合了新根证书签发时间和该根证书被包含在各种信任存储区中的时间之间的差距。我们知道，我们的新 ISRG Root X2 要被广泛信任需要大约 5 年时间，因此，为了使 E1 中间证书签发的证书可信，链中需要进行交叉签名。

我们基本上有两个选择：我们可以从我们现有的 ISRG Root X1 交叉签名新的 ISRG Root X2，或者我们可以从 ISRG Root X1 交叉签名新的 E1 和 E2 中间证书。让我们检查一下每个选择的利弊。

交叉签名新的 ISRG Root X2 证书意味着，如果用户在其信任存储区中具有 ISRG Root X2，则其完整的证书链将是 100% ECDSA，如上所述，为其提供快速验证。在接下来的几年里，随着 ISRG Root X2 被包含在越来越多的信任存储区中，ECDSA 终端实体证书的验证速度将更快，而用户或网站无需进行任何更改。但权衡是，只要 X2 不在信任存储区中，用户代理就必须验证一个包含两个中间证书的链：E1 和 X2 都链接到 X1 根证书。这在证书验证期间需要更多时间。

直接交叉签名中间证书具有相反的权衡。一方面，我们所有的链都将具有相同的长度，在订阅者证书和广泛信任的 ISRG Root X1 之间只有一个中间证书。但另一方面，当 ISRG Root X2 被广泛信任时，我们将不得不经历另一次链切换，以便任何人都能获得全 ECDSA 链的益处。

最后，我们决定提供全 ECDSA 链的选择更重要，因此选择使用第一个选择，并交叉签名 ISRG Root X2 本身。

我们为什么不发布 OCSP 响应器

在线证书状态协议是一种让用户代理实时发现它们正在验证的证书是否已被吊销的方法。每当浏览器想要知道证书是否仍然有效时，它可以简单地访问证书本身中包含的 URL，并获得一个是或否响应，该响应由另一个证书签名，并且可以同样进行验证。这对终端实体证书来说很好，因为响应很小且很快，并且任何给定的用户可能关心（因此必须获取）不同证书集的有效性，具体取决于他们访问的网站。

但中间证书只是野外所有证书的一小部分，通常众所周知，并且很少被吊销。因此，简单地维护一个证书吊销列表 (CRL) 可能效率更高，该列表包含所有众所周知的中间证书的有效性信息。我们的所有中间证书都包含一个 URL，浏览器可以从中获取其 CRL，实际上，一些浏览器甚至将其聚合到他们自己的 CRL 中，这些 CRL 与每次更新一起分发。这意味着检查中间证书的吊销状态不需要在加载网站之前进行额外的网络往返，从而为每个人提供更好的体验。

事实上，最近对规范 CA 的基本要求进行的一项更改 (投票 SC31) 规定，中间证书不再需要包含 OCSP URL；现在，它们可以通过 CRL 来提供其吊销状态。如上所述，我们已经从新中间证书中删除了 OCSP URL。因此，我们不需要发布由 ISRG Root X2 签署的 OCSP 响应器。

综合起来

现在我们已经分享了新证书看起来像它们的样子，还有一件事我们要提一下：我们实际上是如何发布它们的。

创建新的根证书和中间证书是一件大事，因为它们的内容受到严格监管，它们的私钥必须得到精心保护。以至于发布新的证书的行为被称为“仪式”。Let's Encrypt 坚信自动化，因此我们希望我们的仪式尽可能减少人工干预。

在过去的几个月里，我们开发了一个 仪式工具，该工具在适当配置的情况下，可以生成所有所需的密钥、证书和交叉签署请求。我们还构建了一个 演示，展示了我们的配置文件应该是什么样子，并允许任何人自己运行它并检查产生的输出。我们的 SRE 团队搭建了一个完整的复制网络，包括硬件安全模块，并多次演练仪式，确保它能完美运行。我们与我们的技术咨询委员会、社区以及各种邮件列表分享了这个演示，并在此过程中获得了宝贵的反馈，这些反馈实际上影响了我们上面提到的某些决定！最后，9 月 3 日，我们的执行董事在安全的机房与 SRE 团队会面，执行了整个仪式，并将其记录下来以供将来审核。

现在仪式已经完成。我们已经更新了 我们的证书页面，其中包含了所有新证书的详细信息，并且正在开始申请将我们的新根证书纳入各种信任存储库。我们打算在接下来的几周内开始使用我们的新中间证书颁发证书，并在我们的 社区论坛 中发布进一步的公告。

我们希望这次旅程能够让大家对我们的层级结构有所了解，我们期待着继续改进互联网，一次颁发一个证书。我们要感谢 IdenTrust 对我们愿景的早期和持续支持，我们希望改变网络的安全状况，使其变得更好。

为了提供我们的服务，我们依靠来自用户和支持者社区的贡献。如果您的公司或组织想要 赞助 Let's Encrypt，请发送邮件至 sponsor@letsencrypt.org。如果您有能力，我们也请您做出 个人贡献。