Cloudflare Announces Plans to Become a Public Certificate Authority

Cloudflare Announces Plans to Become a Public Certificate Authority Cloudflare has announced its intention to establish a public certificate authority (CA) to expand WebPKI redundancy, submitting applications to major root programs and acquiring an established root from GlobalSign. Cloudflare applied for inclusion in the Chrome, Apple, Microsoft, and Mozilla root programs and agreed to acquire an established root from GlobalSign. The new CA will be ACME-first and require clients to support ACME Renewal Information (RFC 9773) for automated lifecycle management. Cloudflare plans to issue production Merkle Tree Certificates (MTCs) in early 2027 to address post-quantum certificate sizing constraints alongside traditional certificates. Root Program Inclusion and Legacy Compatibility Cloudflare has applied to major root programs including Chrome, Apple, Microsoft, and Mozilla, while signing an agreement to acquire an established root from GlobalSign. Because brand-new roots take years to reach operating systems and devices, and never reach unupdated legacy clients, the 2012 GlobalSign root grants immediate compatibility across older devices, while Cloudflare's newly submitted roots adhere to modern root program policies. Systemic Redundancy and Mandatory Automation Pointing out that the automated, free certificate ecosystem relies heavily on Let's Encrypt, Cloudflare aims to provide systemic redundancy across the broader internet. To ensure seamless migration, the CA will operate as an ACME-first service. To prevent revocation-driven downtime, issuance will strictly require clients to implement ACME Renewal Information (RFC 9773) automation to handle early and staggered renewal windows during security or compliance incidents. Post-Quantum Merkle Tree Certificates Cloudflare intends to lead post-quantum transition efforts by issuing production Merkle Tree Certificates (MTCs) starting in the first quarter of 2027. MTCs minimize TLS handshake bloat caused by larger post-quantum certificate chains. Rather than forcing a sudden transition, Cloudflare will unify traditional WebPKI certificates and MTCs under a single service lifecycle.

Cloudflare宣布将成为公共证书颁发机构 在2024年生日周之际，Cloudflare宣布计划转型为公共证书颁发机构（CA），为整个互联网提供高可用、冗余且支持后量子的自动化证书服务。 Cloudflare已申请加入Chrome、Apple、Microsoft和Mozilla根程序，并达成协议收购GlobalSign现有受信任根。 新CA将基于ACME协议并强制要求客户端支持ACME续订信息（ARI，RFC 9773）。 计划于2027年第一季度开始生产签发面向后量子时代的默克尔树证书（MTC）。 该举措旨在缓解当前免费自动化证书市场高度依赖单一机构带来的系统性风险。 双重根策略与兼容性保障 全新根证书往往需要数年才能在各操作系统和旧设备中分发普及。为此，Cloudflare在申请四大主流根程序的同时，签署协议收购了GlobalSign自2012年起便广泛受信任的根证书。这一策略既保证了对存量旧设备的向下兼容，又符合未来根程序对新证书有效期的安全规范要求。 行业冗余与强自动化运维要求 目前免费自动化证书高度依赖Let's Encrypt，存在一定的系统性单点风险。Cloudflare将采用ACME优先原则，允许现有用户仅通过切换目录URL即可迁移。为避免证书撤销和缩减有效期引发的断网事故，Cloudflare要求订阅方必须支持RFC 9773定义的ARI自动化轮询，以便在安全事件中平滑调度和替换证书。 透明度与后量子证书演进 除公开透明的软件构建、硬件安全模块证明及公开运行状态面板外，Cloudflare还计划成为首批支持后量子认证的CA之一。团队计划在2027年第一季度签发首批生产级默克尔树证书（MTC），在单一CA服务中同时承载经典证书与MTC，协助互联网平滑过渡至后量子加密时代。

Twelve years ago, during Birthday Week 2014, [we turned on Universal SSL](https://blog.cloudflare.com/introducing-universal-ssl/) and nearly doubled the number of encrypted sites on the web overnight, giving free TLS to every site behind Cloudflare, including the ones that never paid us a cent. Encryption stopped being an expensive, time-intensive undertaking and instead became the default. For Birthday Week this year, we are taking the next step on that path. For more than a decade we have been one of the largest consumers of publicly trusted certificates on the Internet, and have never issued a single one ourselves. That is changing. Cloudflare is announcing our intent to become a public certificate authority (CA). Today we are announcing the first concrete milestones in that effort: We have applied for inclusion in the Chrome, Apple, Microsoft, and Mozilla root programs, and we have signed a definitive agreement to acquire an established, broadly trusted root from GlobalSign, so that we can offer certificates with the widest possible device reach the day we begin issuing. We’re also announcing our plans to be one of the first CAs to serve post-quantum certificates, targeting Chrome’s recently announced [Quantum-resistant Root Program](https://blog.google/security/cultivating-a-robust-and-efficient-quantum-safe-https/). We are not issuing certificates yet, and it will be a little while before we do. What we are doing is committing to the work in public, sharing the milestones as they land, and telling you exactly what we are building while working with the root programs and other members of the WebPKI community to achieve this. A brand-new root is not widely useful for years. Even after a root program accepts it, that root has to propagate out into the world's operating systems, browsers, and devices, and it never reaches the large set of devices that have stopped receiving updates, or never received them in the first place. That long tail of older clients is where a great deal of the world’s Internet traffic originates, and where a correspondingly large set of avoidable breakage lives. We believe that all clients deserve the highest level of security possible, regardless of their manufacturer, operating system, or time since last update. Acquiring an existing root with a high degree of trust store coverage across a diverse set of clients solves that on day one. The existing GlobalSign root has been trusted across browsers, operating systems, and devices since 2012, and it reaches older clients that a fresh root never will. The new root that we will be submitting for inclusion in root key programs is built for where the ecosystem is heading, including the programs that are starting to cap how old a trusted root may be. The established root gives us reach across the devices of the past. The new roots give us standing under the policies of the future. We want both to ensure certificates issued by our CA provide the widest set of customer compatibility possible. The free-of-charge, automated certificate model now carries most of the encrypted web, and much of it runs through one remarkable operator. Let's Encrypt issues on the order of ten million certificates a day, serves more than 500 million sites, and passed four billion active certificates in 2025. It is one of the best things to happen to the Internet in twenty years, and we say that as one of its largest users. That success comes with some systemic risk: if the dominant free certificate authority had a bad week, much of the web would have no comparable free, automated alternative ready to take the load. At the certificate pack level, we have spent years building exactly this kind of redundancy for our own customers. Every Cloudflare Universal SSL certificate already ships with a backup certificate, wrapped with a separate key and issued from a different authority, ready to deploy automatically if the primary is ever revoked or compromised. A public CA is that same idea, but at the scale of the whole Internet. To make it easy to adopt, we will be Automated Certificate Management Environment ([ACME](https://www.globalsign.com/en/acme-automated-certificate-management))-first, an open standard protocol that is widely accepted. Automated issuance and renewal through ACME will be the way you get a certificate from us, which means anyone already pointed at any existing free CA can move to us by changing a directory URL, with no new tooling and nothing to re-architect. Cloudflare sits in front of more than 20 percent of global Internet request traffic and terminates TLS for millions of domains, relying on millions of certificates per year to do so. We provision those certificates through multiple CAs, with primary and backup paths so customer services stay up through CA outages and revocation events. That has taught us not just how the WebPKI ecosystem works, but also that it occasionally fails, from the consuming side, the hard way. We have dealt with rate limits, validation edge cases, revocation latency, chain building, and root distribution lag. We have lived through the CA churn of recent years and felt it through our customers. We know what reliable issuance has to look like from the outside, because our customers' uptime has depended on us being resilient and responsive when an issuer has a bad day. And as [certificate maximum validity period decreases](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/#ballot-contents) over the next few years, agentic activity increases, and PQ certs go mainstream, we expect the raw number of certificates we rely on annually on to continue to grow, quickly — and we are not alone. We want to not just solve this problem for ourselves, but be part of providing this utility to the Internet, and ensure that the certificate supply chain for our customers has even more providers. In taking on this new responsibility of being our own CA, we're committed to making the most reliable and resilient CA possible. We intend to build a certificate authority whose reliability depends not just on avoiding mistakes, but as with the rest of Cloudflare’s products, to “fail small” and limit the impact of any one issue. That means instituting processes to design and test recovery before any incident occurs. As an example, we will make renewal automation a condition of issuance. We will only issue to clients that support [ACME Renewal Information](https://www.rfc-editor.org/info/rfc9773/) (ARI), standardized in RFC 9773. Subscribers must maintain automation that polls our renewal endpoint, acts on the renewal windows we publish, and identifies the certificate it is replacing. We're also learning from what we've observed over the past 16 years. We have seen certificate authorities caught between timely revocation and keeping subscribers’ sites online because too many subscribers could not replace their certificates quickly enough. When certificates need to be retired, whether for a compliance issue or a security incident, we can bring forward renewal windows for the affected certificates, spread replacements across the available time, and track replacement issuance. This is just one of the many ways we intend to build. We will be transparent with our issuance stack and operations, publish reproducible builds of the software that signs certificates, attest the hardware security modules that hold our keys, and run a public dashboard for issuance health and incidents. Audits are point-in-time and tell you a CA passed, not how it runs on an ordinary Tuesday. We want root programs, researchers, and ordinary site owners to watch how a modern CA actually operates between audits. We also intend to lead on where certificates are going, not just where they are. We plan to be one of the first CAs to issue production Merkle Tree Certificates (MTCs), with the first certificates issued in the first quarter of 2027. MTCs are a new and far more compact way to deliver publicly trusted certificates, designed for a post-quantum world where traditional certificate chains grow large enough to strain TLS handshakes. We have been championing the [standards-based proposal](https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/) for MTCs at the IETF, and earlier this year, [Chrome named MTCs](https://blog.google/security/cultivating-a-robust-and-efficient-quantum-safe-https/) as the preferred path for post-quantum authentication. Issuing them in production allows us to protect Cloudflare customers as well as the wider Internet against the post-quantum threat, with real volume behind a transition the whole web has to make. We’ve shared much more about MTCs and what this new Web Public Key Infrastructure (PKI) will look like [in a blog post on the topic](http://blog.cloudflare.com/pq-ca-with-mtcs). We do not expect that transition to be sudden. Much of the Internet will continue to rely on classic certificates and existing WebPKI for many more years. But across that window we expect MTCs to take a steadily growing share of issuance, and that is why we are building one service that does both. By carrying classic certificates and Merkle Tree Certificates under one CA, with one lifecycle and one set of guarantees, customers can adopt at the pace that suits them and help the web make the crossing without a hard cutover. Customers should not have to pick a side of a multi-decade migration, run two systems, or rebuild when the balance shifts. In addition to providing certificate packs via Universal SSL for our customers, Cloudflare consumes certificates from many different CAs to run our systems and internal operations. Just like our other products, we will be [Customer Zero](https://www.cloudflare.com/the-net/top-of-mind-security/customer-zero/) for the new CA and its certificates (both WebPKI and MTC), ensuring that all aspects of the new systems and processes meet our high internal standards, and that our CA’s infrastructure is exercised at Cloudflare scale. We are working through the application and approval process with each of the core web root key programs. These processes happen in the open, and we’ll share more updates as they proceed, through to the first Merkle Tree Certificates in early 2027. If you want to follow this work or be one of the first to use a Cloudflare CA certificate in the future, you can [register for updates](http://cloudflare.com/resource/certificate-authority). And if you’d like to be part of building out this new capability inside Cloudflare, we’re [hiring](https://boards.greenhouse.io/cloudflare/jobs/8237801?gh_jid=8237801)! As we build out this new capability, we will continue to work closely with the network of partner public CAs we have relied on for many years — 16 in fact! — as we all work together to ensure a trusted and open Internet. When we launched Universal SSL, the argument was simple: every byte that flows encrypted across the Internet makes it harder to intercept, throttle, or censor, and the open web is something we all build together. A public, redundant, transparent certificate authority is that same argument carried one layer down, to the trust that makes the encrypted web possible in the first place. We have been working toward this for a long time, and we are glad to finally be on the road. Happy Birthday Week!