Cloudflare想自行签发证书，其计划立足于免费CA集中问题

TL;DR. Cloudflare宣布有意成为公共证书颁发机构。它已向Chrome、Apple、Microsoft和Mozilla的根证书计划提出申请，并签署了从GlobalSign收购根证书的最终协议。

核心要点

证书的使用者变成证书的签发者. 大多数基础设施公司只站在证书关系的一边。它们申请证书、安装证书，在CA出事时抱怨。Cloudflare一直牢牢站在使用的一方。按它自己的说法，它从未亲自签发过任何一张公开受信任的证书。.
为什么Cloudflare有资格提出这个问题. Cloudflare建立CA的理由，始于它作为客户的地位。它处在全球互联网请求流量20%以上的前端。它为数百万个域名终结TLS，每年依赖数百万张证书。它通过Universal SSL为客户提供证书包，同时也从许多不同的CA获取证书，用于运行自己的系统和内部业务。.
集中问题. 支撑这一论点的数字令人瞩目。Let's Encrypt每天签发约一千万张证书。它服务超过5亿个网站，并在2025年突破了40亿张有效证书。这只是一家免费CA的数字，描绘的是一个加密严重依赖单一组织的网络。.
买下根证书，而不是等待. 公告中最务实的决定与根证书有关。Cloudflare表示，它已签署最终协议，从GlobalSign收购一个成熟且广受信任的根证书。来源直接给出了理由：全新的根证书多年内都难以广泛发挥作用。相比之下，现有的GlobalSign根证书自2012年起就在各浏览器、操作系统和设备上受到信任。.

多年来，Cloudflare一直依赖16家合作公共CA，自己从未签发过一张公开受信任的证书。如今它打算成为CA，而有意思的是其设计：在同一个CA下同时承载传统证书和Merkle Tree Certificates，并从一开始就内置故障隔离。

证书的使用者变成证书的签发者 #

大多数基础设施公司只站在证书关系的一边。它们申请证书、安装证书，在CA出事时抱怨。Cloudflare一直牢牢站在使用的一方。按它自己的说法，它从未亲自签发过任何一张公开受信任的证书。

这种情况即将改变，至少Cloudflare表示它打算如此。该公司宣布有意成为公共证书颁发机构。公告对当前进展的表述很谨慎，本文也应如此。Cloudflare尚未签发证书。从ACME接口到续期规则，再到对Merkle Tree Certificate的支持，有关这项服务行为的一切都是计划的陈述，而不是对运行中系统的描述。

让这份公告可信的不是雄心，而是已经看得见的准备工作。Cloudflare已申请加入Chrome、Apple、Microsoft和Mozilla的根证书计划。它表示正在与每个核心网络根密钥计划推进申请和审批流程，并指出这些流程是公开进行的。原则上，任何人都可以关注申请是否成功。

为什么Cloudflare有资格提出这个问题 #

Cloudflare建立CA的理由，始于它作为客户的地位。它处在全球互联网请求流量20%以上的前端。它为数百万个域名终结TLS，每年依赖数百万张证书。它通过Universal SSL为客户提供证书包，同时也从许多不同的CA获取证书，用于运行自己的系统和内部业务。

为保证客户服务在线，Cloudflare通过多家CA获取这些证书，设有主路径和备用路径，使客户服务在CA故障和吊销事件中保持运行。它多年来依赖的合作公共CA网络共有16家。

这套备用机制值得细看，因为它展示了Cloudflare如何看待故障。每张Universal SSL证书都已附带一张备用证书，使用单独的密钥封装，并由另一家机构签发。一旦主证书被吊销或遭到入侵，备用证书即可自动部署。这是从关系中客户一方构建的、针对任何单一CA出问题的对冲。

但这种对冲也有上限。你只能在现有的CA之间分散，而来源认为，有能力的CA的供给比看上去更单薄。

集中问题 #

支撑这一论点的数字令人瞩目。Let's Encrypt每天签发约一千万张证书。它服务超过5亿个网站，并在2025年突破了40亿张有效证书。这只是一家免费CA的数字，描绘的是一个加密严重依赖单一组织的网络。

来源得出了显而易见的结论，并加上了恰当的限定：如果占主导地位的免费证书颁发机构遭遇糟糕的一周，网络的大部分将没有可比的免费自动化替代方案来承接负载。这是对一种假设情况的陈述，Cloudflare也是这样表述的。它并没有声称这样的一周已经发生，或即将到来。

即便如此，其中的逻辑并不难理解。免费的自动化CA只有在紧急情况发生之前就已存在，才是一种韧性选项。Cloudflare的卖点在于，它能以相应规模提供第二个这样的CA。我认为这是公告中最有力的商业和技术理由，而且不依赖计划中任何更具推测性的部分。一个只有一家主导的免费CA、别无其他选择的网络，无论那家CA运营得多好，都是一个存在单点故障的网络。

维度	传统免费自动化CA（Let's Encrypt）	拟议中的Cloudflare公共CA
信任锚策略	ISRG Root X1 / X2（2015年以后建立的自有根证书）	收购的GlobalSign根证书（自2012年起受信任）+ 新根证书
签发协议	标准ACME（RFC 8555）	强制执行ARI（RFC 9773）的ACME
吊销模式	CRL / OCSP + 紧急批量替换订阅者证书	通过ARI端点协调提前续期
后量子路径	混合X.509签名评估中	与传统X.509共存的原生Merkle Tree Certificates（MTC）
规模与初始负载	5亿以上网站，每天约1000万张证书	在全球20%以上网络流量上进行Customer Zero验证

买下根证书，而不是等待 #

公告中最务实的决定与根证书有关。Cloudflare表示，它已签署最终协议，从GlobalSign收购一个成熟且广受信任的根证书。来源直接给出了理由：全新的根证书多年内都难以广泛发挥作用。相比之下，现有的GlobalSign根证书自2012年起就在各浏览器、操作系统和设备上受到信任。

根信任之所以缓慢，是因为根证书装在设备里，而设备更新很慢。一个新根证书即使被所有计划接受，也可能在较旧的手机或嵌入式系统上无法通过验证。收购一个自2012年起就已部署的根证书，至少按来源的说法，可以绕过这段等待。

Cloudflare并没有完全放弃新根证书这条路。它还将提交一个新根证书申请加入根密钥计划，并称其面向生态系统的发展方向而构建，包括一些开始限制受信任根证书年龄上限的计划。最后这个细节提醒我们，年龄是一把双刃剑。受信任根证书的年龄对设备覆盖而言是一项资产，而一些计划正在走向限制受信任根证书的年龄。同时运营收购来的根证书和新提交的根证书，看起来是对这种张力的回应，不过来源并没有用这些话来阐明其中的道理。

附带条件的ACME优先服务 #

采用环节是许多CA公告变得含糊的地方。Cloudflare说得很具体。它的公共CA将以ACME为先，也就是说，它使用现有自动化工具已经在用的Automated Certificate Management Environment协议。其说法是，任何已经指向现有免费CA的人，只需更改一个目录URL，就能迁移到Cloudflare的CA，无需新工具，也无需重新设计架构。这是计划，而不是经过检验的迁移路径，应当这样看待。但一行配置的改动是正确的目标，因为让人们停留在默认选项上的正是迁移成本。

问题在于一项大多数ACME用户此前无需满足的要求。Cloudflare只会向支持ACME Renewal Information（即ARI，已在RFC 9773中标准化）的客户端签发证书。订阅者必须维护自动化程序，定期轮询Cloudflare的续期端点，按照Cloudflare公布的续期窗口行事，并标识出要替换的证书。

这是一个坚定的立场，我认为它是对的。但它也引出了一个合理的采用问题：只服务支持ARI的客户端的CA，比服务任何拥有ACME库的用户的CA范围更窄。来源没有说明这在今天会排除多少客户端，所以我不做猜测。来源说明的是Cloudflare为什么想要这一约束。

不让网站中断的吊销 #

Cloudflare表示，它在过去16年里观察到了一些情况，其中一项观察推动了这一设计。它看到证书颁发机构在及时吊销和保持订阅者网站在线之间进退两难。

这种张力对任何CA都是真实存在的。迅速吊销证书可以保护公众，但如果订阅者无法足够快地替换证书，依赖该证书的所有网站都可能下线。夹在中间的CA要么延迟吊销，要么让客户中断。

ARI就是Cloudflare的答案。Cloudflare表示，当证书需要退役时，它可以提前相关证书的续期窗口。由于订阅者必须轮询续期端点并按公布的窗口行事，CA就能在硬性吊销到来之前引导他们完成替换。这一机制被描述为Cloudflare打算具备的能力，而不是它作为CA已经证明的能力。不过逻辑是自洽的：轮询要求的存在，正是为了让这个杠杆发挥作用。

同样的思路也体现在一个更广泛的设计目标中。Cloudflare打算打造一家证书颁发机构，其可靠性不仅取决于避免错误，还像Cloudflare的其他产品一样，取决于小范围失败、限制任何单一问题的影响。避免错误对CA而言是必要的，但没有任何CA能完美做到。通过设计让错误保持在可控范围内，是更诚实的工程立场。

超越审计的透明度 #

公共CA通常靠审计来评判。来源直言审计的局限：审计只反映某一时间点，只能告诉你CA通过了审计。它无法告诉你CA在此后任意一个星期二在做什么。

Cloudflare的回应是，它将公开签发证书所用软件的可复现构建。这被定位为一项承诺，而不是已经完成的交付。可复现构建让外部人士能够核实签名路径中运行的二进制文件与公开的源代码一致，这是一种持续性的属性，而审计报告做不到这一点。这是否足够，将取决于Cloudflare实际公开了什么，以及是否有人去核查。

公告的后半部分：Merkle Tree Certificates #

后量子部分是公告看得最远的地方。Cloudflare宣布计划成为首批提供后量子证书的CA之一，并计划在2027年第一季度签发首批Merkle Tree Certificates。来源的另一段则说首批MTC预计在2027年初推出。两者都是计划。

来源将MTC描述为一种交付公开受信任证书的新方式，而且紧凑得多。这一措辞是一种描述，而在我依据的段落中，来源没有提供测量数据，所以我无法说明它到底紧凑多少。Cloudflare表示，它一直在IETF推动关于MTC的基于标准的提案。它还提到，Chrome今年早些时候已将MTC列为后量子认证的首选路径。这是一件已经发生的事，而且很重要，因为浏览器厂商公开表达的偏好，正是把一项提案变成CA可以据以规划的东西的关键。

Cloudflare并不认为过渡会是突然的。它预计在未来许多年里，互联网的大部分仍将依赖传统证书和现有的WebPKI。在这段时间内，它预计MTC在签发量中的份额会稳步增长。这些都是预期，来源也是这样标注的。

一个CA，一个生命周期 #

由此而来的架构选择，是我认为最有说服力的部分。新CA的设计是在同一个CA下承载传统证书和Merkle Tree Certificates，采用同一个生命周期和同一套保证。这样客户就能按适合自己的节奏采用，并在没有硬切换的情况下帮助网络完成过渡。

另一种做法是两个并行的CA、两套流程，以及在某个时间点的强制迁移。硬切换是改变证书生态系统风险最高的方式，而来源表明的目标正是避免它。措辞是有所保留的，这样也对：这是一个尚未签发证书的CA的设计意图。

这也符合激励格局。Cloudflare预计，随着最长有效期缩短、智能体活动增加以及后量子证书成为主流，它每年依赖的证书数量将继续增长。更多的证书、更频繁的签发，要求自动化，也要求一个把续期当作一等操作的CA。一个围绕ARI和单一生命周期构建的系统，是对这一预期的合理回应，不过这一预期本身是预测，而不是测量。

Customer Zero #

在公众依赖一个CA之前，如何测试它？Cloudflare的答案是成为自己的第一个客户。它将成为新CA及其证书（包括WebPKI和MTC）的Customer Zero。其目的是确保新系统和流程的各个方面都达到Cloudflare严格的内部标准，并让CA的基础设施在Cloudflare的规模下得到实际运行。

结合前面的数字，这是一项繁重的内部负载：在一家处于全球请求流量20%以上前端的公司中，每年数百万张证书。运营的头几年是否顺利，这些说法无法告诉我们。它们展示的是一个合理的工作顺序。该公司从自己所建之物的重度用户起步，背后有多CA配置、备用路径和16家合作CA的经历。

有必要坦白说明缺了什么。来源中没有报告Cloudflare自有CA的签发量、错误率、验证延迟或事故记录，因为这样的记录尚不存在。这份公告是一份意向声明，有申请、收购协议和设计作为支撑。它不是业绩记录。

值得关注的方面 #

这究竟会成为对WebPKI有意义的补充，还是只是一份有趣的公告，取决于三件事。

第一是根证书计划。Cloudflare已向Chrome、Apple、Microsoft和Mozilla提出申请，流程公开进行。关注这些流程是了解计划进展最直接的方式，而结果是任何说法都无法让我预测的。

第二是ARI要求。坚持要求支持RFC 9773的CA，是在押注续期自动化可以在其订阅者群体中推广开来。如果押对了，Cloudflare就能在证书必须退役时提前续期窗口，这正是它针对所见吊销困境给出的答案。如果押错了，采用速度会比一行配置即可迁移的说法所暗示的更慢。

第三是2027年第一季度。那是Cloudflare计划推出首批Merkle Tree Certificates的时间。悬而未决的问题是，鉴于它自己认为互联网的大部分在未来许多年仍会停留在传统证书上，它所预期的稳步增长的份额实际会增长得多快。该公司表示，这一过渡不应需要硬切换。2027年第一季度将是第一次机会，看看一个同时承载两种证书的CA能否做到这一点。

对各行业的意义 #

一家边缘基础设施提供商成为大规模自动化公共证书颁发机构，会改变多个技术领域的运营风险和PKI规划。

云基础设施与边缘网络 #

在边缘规模上运营公共CA，可减少对第三方验证API和CRL的外部依赖。通过把反向代理边缘终结与自动化的ACME ARI续期结合起来，基础设施提供商可以让客户免受上游证书颁发机构故障的影响。

企业PKI与DevOps团队 #

依赖Let's Encrypt提供公共端点的组织，获得了一个可信的自动化替代方案。不过，由于强制执行RFC 9773（ARI），团队在切换目录端点之前，必须审查自己的ACME客户端（Certbot、Lego、Caddy、Traefik），确保已启用ARI支持。

浏览器厂商与根证书治理 #

根证书计划（Chrome、Mozilla、Apple、Microsoft）面临一个大规模自动化CA不断增多的生态系统。双轨根证书做法（收购一个2012年的旧根证书，同时提交一个新根证书）既能应对日益限制根证书寿命的浏览器政策，又能保持对旧设备的向后兼容。

结论 #

Cloudflare成为公共证书颁发机构的举动，针对的是现代WebPKI中一个真实的结构性弱点：免费自动化证书签发的极度集中。通过结合成熟的GlobalSign根证书、严格的ARI续期自动化，以及通往后量子Merkle Tree Certificates的桥梁，这一设计着眼于运营韧性，而不仅仅是证书供应。成败将取决于根证书计划的审批，以及客户端工具能否在2027年推出之前迅速采用ARI标准。

常见问题 #

我现在可以把ACME客户端切换到Cloudflare的CA吗？

还不行。Cloudflare已宣布意向、签署根证书收购协议，并向主要根证书计划提交了申请。公开签发将在根证书计划批准后推出。

什么是ACME Renewal Information（ARI），为什么它很重要？

ARI（RFC 9773）是ACME协议的扩展，允许证书颁发机构告知订阅者证书应在何时续期。这使CA能够在计划内吊销之前平稳协调提前续期，防止网站中断。

Merkle Tree Certificates（MTC）与标准X.509证书有何不同？

MTC用锚定在可公开验证日志中的Merkle包含证明，取代传统的逐张加密签名。这大幅减少了证书大小和传输开销，使其成为后量子TLS认证的首选候选方案。

参考文献 #

Cloudflare, (2026). 为整个互联网打造证书颁发机构 ⧉. Cloudflare Blog.
IETF, (2024). RFC 9773：Automated Certificate Management Environment（ACME）Renewal Information（ARI） ⧉. IETF.
IETF, (2025). 用于TLS的Merkle Tree Certificates ⧉. IETF.
Chrome Root Program, (2026). 关于后量子认证的政策与考量 ⧉. Chromium Projects.

最近审阅 2026-09-20.

最近审阅 2026-10-27.

重新发布本文

Cloudflare想自行签发证书，其计划立足于免费CA集中问题 — Sebastien Rousseau

Cloudflare宣布有意成为公共证书颁发机构。它已向Chrome、Apple、Microsoft和Mozilla的根证书计划提出申请，并签署了从GlobalSign收购根证书的最终协议。

本文采用以下许可协议 Creative Commons Attribution 4.0 International. 重新发布需注明原始 URL 出处。

Cloudflare想自行签发证书，其计划立足于免费CA集中问题 — Sebastien Rousseau

Cloudflare宣布有意成为公共证书颁发机构。它已向Chrome、Apple、Microsoft和Mozilla的根证书计划提出申请，并签署了从GlobalSign收购根证书的最终协议。

Originally published at https://sebastienrousseau.com/zh-hans/2026-09-20-cloudflare-xiang-zixing-qianfa-zhengshu-jihua/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER