Let's Encrypt 是 Cloudflare 用于颁发 TLS 证书的一家公开可信的证书颁发机构 (CA)。它一直依赖于两个不同的证书链：一个使用 IdenTrust 提供的根证书进行交叉签名，后者是诞生自 2000 年的一家全球可信 CA；另一个则使用 Let's Encrypt 自己的根证书，也就是 ISRG Root X1。自 Let's Encrypt 推出以来，ISRG Root X1 的设备兼容性一直在稳步提升。
Let's Encrypt 与 IdenTrust 签订的交叉签名证书链协议将于 2024 年 9 月 30 日到期。在此之后，服务器将无法再提供通过交叉签名链签名的证书。所有 Let's Encrypt 证书都将改为使用 ISRG Root X1 CA。
2016 年之后发布的大多数设备和浏览器版本不会因这一变更而遇到任何问题，因为这些客户端的信任存储中已安装 ISRG Root X1。这些现代浏览器和操作系统的设计目标是保持敏捷性和灵活性，且拥有可升级的信任存储，完成更新后即可添加新的证书颁发机构。
证书链变更将会影响旧设备和系统，例如运行 Android 版本 7.1.1（2016 年发布）或更早版本的设备，因为这些设备完全依赖于交叉签名链，并且其信任存储中缺少 ISRG Root X1。这些客户端在访问由 Let's Encrypt 证书提供保护的域时，将会收到 TLS 错误或警告。我们自己查看了数据，发现所有 Android 请求中占 2.96% 的请求来自将会受到这一变更影响的设备。这意味着，很大一部分流量将无法访问互联网。我们致力于让这部分用户保持在线，并将修改证书管道以便可以继续为使用旧设备的用户提供服务，而无需客户进行任何手动修改。
为所有人构建更好的互联网
过去，Cloudflare 展开了“不让一个浏览器掉队”之类的努力，帮助确保在基于 SHA-1 的算法遭到弃用时，我们能够继续为客户端提供支持。现在，我们将采用同样的方法应对即将到来的 Let's Encrypt 变更。
我们已决定从 Cloudflare 将 Let's Encrypt 指定为证书颁发机构的所有流程中移除此 CA，这将会影响到使用 Universal SSL 的客户以及在“默认 CA”中选择 SSL for SaaS 的客户。
从 2024 年 6 月开始，在交叉签名链到期之前的一个证书生命周期（90 天），Cloudflare 将开始迁移需要续订的 Let's Encrypt 证书，改为使用其他 CA，以确保与受变更影响的旧设备兼容。也就是说，以后客户在明确请求将 Let’s Encrypt 作为 CA 时才会收到 Let's Encrypt 证书。
Let's Encrypt 所做的更改是必要的。为了推动对新标准和协议的支持，我们需要提高公钥基础设施 (PKI) 生态系统的敏捷性。通过淘汰交叉签名链，Let's Encrypt 将推动设备、浏览器和客户端支持自适应信任存储。
不过，根据我们对过去类似变更的观察，这一方面会推动采用新标准，但另一方面会对经济落后地区的用户产生很大的影响，这些地区获得新技术的机会比较有限。
Cloudflare 的使命是帮助构建更好的互联网，这意味着为全球用户提供支持。我们之前发布了一篇关于 Let's Encrypt 证书链变更的博客文章，提醒客户如果认为会受到这一变更的影响，就要换用证书颁发机构。不过，确定这一变更带来的影响并非易事。因信任存储不兼容导致的错误率主要记录在客户端上，这降低了域所有者的可见性。此外，虽然当下可能没有来自不兼容设备发来的请求，但这并不能保证未来用户的访问不会中断。
Cloudflare 证书管道经过多年的发展已兼具韧性和灵活性，让我们能够顺利地适应此类变更，且不会对客户产生任何负面影响。
Cloudflare 如何构建强大的 TLS 证书管道
如今，Cloudflare 代表客户管理着数千万个证书。对我们来说，成功的证书管道意味着：
客户始终可以获得所需域的 TLS 证书
CA 相关问题不会影响客户获取证书的能力
采用最佳安全实践和现代标准
持续优化，以备未来扩展
为一系列客户端和设备提供支持
每年，Cloudflare 都会在证书管道中推出新增的优化功能，以维持最高水平的服务。我们的做法如下所述……
确保客户始终可以获得所需域的 TLS 证书
自 2014 年推出 Universal SSL 以来，Cloudflare 一直负责为受我们网络保护的每个域颁发和提供 TLS 证书。这看似微不足道，但必须成功执行几个步骤才能使域接收证书：
域所有者需要为每次证书颁发和续订完成域控制验证。
证书颁发机构需要验证用于颁发证书的域控制验证令牌。
需要检查 CAA 记录，它规定了哪些 CA 可用于域，确保只有已获授权的 CA 才能颁发证书。
证书颁发机构必须可用，才能颁发证书。
上述每个步骤都需要多方协调，包括域所有者、CDN 以及证书颁发机构。Cloudflare 希望能够掌控自己平台的成功。这就是我们将确保成功完成上述每个步骤作为自己职责的原因。
我们确保每次客户只需付出最少的努力即可完成证书颁发和续订。要获得证书，域所有者必须完成域控制验证 (DCV)，证明它确实拥有该域。发起证书请求后，CA 将会返回 DCV 令牌，域所有者需要将此令牌放入 DNS 记录或 HTTP 令牌中。如果您使用 Cloudflare 作为 DNS 服务提供商，Cloudflare 将代表您完成 DCV 添加，自动将 CA 返回的 TXT 令牌放入您的 DNS 记录中。或者，如果您使用外部 DNS 服务提供商，我们提供将 DCV 委托给 Cloudflare 的选项，可实现自动续订，无需任何客户干预。
放入 DCV 令牌之后，证书颁发机构 (CA) 开始验证。CA 从多个有利位置进行验证以防范欺骗行径。不过，由于这些检查是从多个国家/地区和自治系统 (ASN) 完成，可能会触发 Cloudflare WAF 规则，导致 DCV 检查遭到阻止。我们确保及时更新 WAF 和安全引擎，用于识别 CA 发出的这些请求，从而确保检查请求永远不会遭到阻止，成功完成 DCV。
由于内部要求或合规规定，某些客户拥有 CA 首选项。为防止未经授权的 CA 为域颁发证书，域所有者可以创建证书颁发机构授权 (CAA) DNS 记录，指定允许哪些 CA 为该域颁发证书。为确保客户始终可以获得证书，Cloudflare 会在请求证书之前检查 CAA 记录，了解应该使用哪些 CA。如果 CAA 记录阻止了 Cloudflare 管道中可用的所有 CA 且客户没有从其首选的 CA 上传证书，那么 Cloudflare 会代表客户添加 CAA 记录，确保其可以获得颁发的证书。我们会尽可能优化对客户首选 CA 的支持。否则，就需要我们通过确保域始终拥有可用的 TLS 证书来防止服务中断，即使证书不是由客户首选 CA 颁发。
如今，Cloudflare 不是一家公开可信的证书颁发机构。因此，我们依赖于选用的 CA 来实现高可用性。但是，100% 正常运行是不切实际的期望。相反，Cloudflare 证书管道需要做好准备，以防 CA 不可用。
确保与 CA 相关的问题不会影响客户获取证书的能力
Cloudflare 喜欢未雨绸缪，即防患于未然。CA 不可用的情况并不少见，有时是因为断电故障，但更常见的原因是 CA 设置了频繁的维护期，在此期间会在一段时间变得不可用。
Cloudflare 的职责是确保 CA 冗余，这正是我们总是准备好多个 CA 用于颁发证书的原因，从而一直确保高可用性。如果您发现其他 CA 颁发 Universal SSL 证书，这是有意为之。我们在多个 CA 之间平均分配负载，以免出现单点故障。此外，我们会密切关注延迟和错误率，以便检测问题并自动切换到其他可用且性能良好的 CA。您可能有所不知，其中一个 CA 每月大约有 4 个计划的维护期。在进行维护时，Cloudflare 自动化系统会无缝启动，确保一切顺利运行。这种做法非常有效，无需再呼叫内部团队，因为一切均_正常运行。_
采用最佳安全实践和现代标准
安全性一直是并将继续是 Cloudflare 的首要任务。因此，维持最高标准来保护客户的数据和私钥安全至关重要。
过去十多年来，CA/浏览器论坛主张将证书有效期从 5 年缩短至 90 天，并以此作为行业规范。这种转变有助于最大限度地降低密钥泄露风险。当证书每 90 天更新一次时，其私钥仅在该期限内依旧有效，从而缩短了不良行为者利用泄露的密钥资料的窗口期。
我们完全接受这一变化，并且已将 90 天作为默认的证书有效期。通过确保定期轮换密钥，增强安全态势；促使我们开发“DCV 委托”之类的工具，推动频繁续订证书的自动化，且不增加开销。这使我们能够为希望高频率轮换私钥的客户提供有效期短至两周的证书，同时客户不必担心会导致证书续订失败。
Cloudflare 一直处于采用新协议和标准的前沿。众所周知，Cloudflare 支持一种新协议后，采用率就会飙升。本月，我们将添加对 Google Trust Services 颁发的 ECDSA 证书的支持。使用 ECDSA，您可以获得与 RSA 相同的安全级别，但密钥更小。较小的密钥意味着更小的证书以及更少的数据来建立 TLS 连接，从而加快连接速度并缩短加载时间。
持续优化，以备未来扩展
如今，Cloudflare 每天颁发近 100 万个证书。随着最近缩短证书有效期的转变，我们将继续改进密钥管道，提高稳健性。但是，即便 Cloudflare 管道可以处理大量工作负载，我们仍然需要依赖 CA 与我们一起扩展。每集成一个 CA，我们就会立即成为他们最大的客户之一。我们要求 CA 坚持高标准，并推动他们改善基础设施以扩大规模。通过要求 CA 处理更多的证书颁发请求，这不仅有利于 Cloudflare 的客户，而且还有助于维持互联网访问。
现在，鉴于 Let's Encrypt 缩短了其信任链，Cloudflare 将为证书管道添加额外的改进措施，确保为所有用户提供最佳设备兼容性。
支持所有客户端，包括旧客户端和现代客户端
即将到来的 Let's Encrypt 变更，将使旧设备无法向受到 Let's Encrypt 证书保护的域或应用程序发出请求。Cloudflare 不希望切断来自世界任何地方的互联网访问，也就是说，虽然这项变更即将生效，但我们会继续努力为客户提供最佳的设备兼容性。
得益于最近的所有增强功能，Cloudflare 能够减轻对 Let's Encrypt 的依赖，同时不影响证书管道的可靠性或服务质量。在变更生效之前的一个证书生命周期（90 天），我们会开始转向要求证书改用其他 CA，也就是与受影响的设备兼容的 CA。如此一来，我们将缓解变更带来的影响，无需客户采取任何行动。只有专门选择了 Let's Encrypt 作为 CA 的客户，才会继续使用 Let's Encrypt。
即将到来的 Let's Encrypt 变更可能会发生的情况
Let's Encrypt 的交叉签名链将于 2024 年 9 月 30 日到期。虽然 Let's Encrypt 计划在 2024 年 6 月 6 日停止从交叉签名链颁发证书，但是 Cloudflare 将继续为所有 Let's Encrypt 证书提供交叉签名链，直到 2024 年 9 月 9 日为止。
在变更生效之前的 90 天或一个证书生命周期，Cloudflare 会开始将 Let's Encrypt 证书转换为使用其他证书颁发机构。我们将对 Cloudflare 负责 CA 选择的所有产品实施这一变更，也就是说，会为使用 Universal SSL 的客户以及在“默认 CA”中选择 SSL for SaaS 的客户自动完成此项变更。
所有专门选择 Let's Encrypt 作为其 CA 的客户，都会收到一封电子邮件通知，其中包含其 Let's Encrypt 证书列表，以及关于 Cloudflare 是否可以看到从旧设备发出对这些主机名的请求的信息。
2024 年 9 月 9 日之后，Cloudflare 将使用 ISRG Root X1 证书链为所有 Let's Encrypt 证书提供服务。根据所使用的证书产品，您可能会遇到以下情况：
Universal SSL
对于 Universal SSL，Cloudflare 会选择用于颁发域证书的 CA，这让我们能够为客户选择最佳证书。如果您使用 Universal SSL，则无需进行任何更改来为此变更做好准备。Cloudflare 会自动将您的证书转换为使用某个更兼容的 CA。
高级证书
对于 Advanced Certificate Manager，客户可以专门选择其想使用的 CA。如果客户专门选择将 Let's Encrypt 作为 CA，我们会尊重这种选择，因为客户可能由于内部要求而专门选择了这个 CA，或者因为他们已经实施了证书锁定，虽然 Cloudflare 强烈建议不要这样做。
如果发现使用 Let's Encrypt 颁发的高级证书的域将受到变更的影响，我们会发送电子邮件通知，告知这些客户哪些证书使用 Let's Encrypt 作为其 CA，以及这些域是否会接收受到变更影响的客户端发来的请求。客户则负责改用其他 CA 服务提供商，如果他们选择这样做的话。
SSL for SaaS
对于 SSL for SaaS，客户有两个选项：一是使用默认的 CA，也就是 Cloudflare 选择的颁发机构；二是指定要使用的 CA。
如果您将 CA 选择权交给 Cloudflare，我们会自动使用设备兼容性更高的 CA。
如果您为自定义主机名指定某个 CA，我们会尊重您的选择。我们将向 SaaS 提供商和平台发送电子邮件，告知他们哪些自定义主机名会接收旧设备发出的请求。客户则负责改用其他 CA 服务提供商，如果他们选择这样做的话。
自定义证书
若直接与 Let's Encrypt 集成并且使用自定义证书将 Let's Encrypt 证书上传到 Cloudflare，则只要您选择“兼容”或“现代”捆绑方法并在 2024 年 9 月 9 日之前上传这些证书，您的证书将会与交叉签名链捆绑在一起。9 月 9 日之后，我们将会把所有 Let's Encrypt 证书与 ISRG Root X1 链捆绑在一起。我们始终采用“用户定义的”捆绑方法，为上传到 Cloudflare 的证书链提供服务。如果您使用此方法上传 Let's Encrypt 证书，则需要确保在 2024 年 9 月 30 日（也就是 CA 到期日）之后上传的证书均包含正确的证书链。
此外，如果您管理连接到应用程序的客户端，我们建议您更新信任存储以添加 ISRG Root X1。如果您使用证书锁定，则请移除或更新锁定。一般而言，我们不鼓励客户固定自己的证书，因为这种做法通常会导致在证书续订或 CA 变更期间出现问题。
总结
互联网标准将会继续发展和完善。在支持和拥抱这些变更的同时，我们也应意识到，我们有责任让用户保持在线，并在不易获得新技术的全球各地维持用户的互联网访问。使用 Cloudflare 服务，您始终可以选择最适合的应用程序设置。
有关此次变更的更多信息，请参阅 Cloudflare 开发人员文档。