Cloudflare Wants to Issue Its Own Certificates, and Its Plan Rests on a Free-CA Concentration Problem

Translation pending — read the English original while we localise.

Cloudflare has relied on 16 partner public CAs for years without ever issuing a publicly trusted certificate itself. It now intends to become one, and the interesting part is the design: classic certificates and Merkle Tree Certificates under one CA, with failure containment built in from the start.

A certificate consumer becomes a certificate issuer #

Most infrastructure companies stay on one side of the certificate relationship. They request certificates, install them, and complain when a CA has an incident. Cloudflare has been firmly on the consuming side. By its own account, it has never issued a single publicly trusted certificate itself.

That's about to change, or at least Cloudflare says it intends it to. The company is announcing its intent to become a public certificate authority. The announcement is careful about where things stand today, and so should this article be. Cloudflare is not issuing certificates yet. Everything about the service's behaviour, from its ACME interface to its renewal rules to its Merkle Tree Certificate support, is a statement of plan rather than a description of a running system.

What makes the announcement credible isn't ambition but the groundwork already visible. Cloudflare has applied for inclusion in the Chrome, Apple, Microsoft and Mozilla root programs. It says it is working through the application and approval process with each of the core web root key programs, and it notes that these processes happen in the open. Anyone can, in principle, watch whether the application succeeds.

Why Cloudflare is positioned to ask the question #

Cloudflare's case for building a CA starts with its position as a customer. It sits in front of more than 20 percent of global Internet request traffic. It terminates TLS for millions of domains and relies on millions of certificates per year. It provides certificate packs via Universal SSL for its customers, and it also consumes certificates from many different CAs to run its own systems and internal operations.

To keep customer services up, Cloudflare provisions those certificates through multiple CAs, with primary and backup paths so customer services stay up through CA outages and revocation events. The network of partner public CAs it has relied on for many years numbers 16.

The backup mechanism deserves a closer look because it shows how Cloudflare thinks about failure. Every Universal SSL certificate already ships with a backup certificate, wrapped with a separate key and issued from a different authority. If the primary is ever revoked or compromised, the backup is ready to deploy automatically. That's a hedge against any single CA going wrong, built from the customer's side of the relationship.

It's also a hedge that has a ceiling. You can only diversify across the CAs that exist, and the source argues that the supply of capable ones is thinner than it looks.

The concentration problem #

The numbers behind that argument are striking. Let's Encrypt issues on the order of ten million certificates a day. It serves more than 500 million sites and passed four billion active certificates in 2025. Those are figures for a single free CA, and they describe a web whose encryption leans heavily on one organisation.

The source draws the obvious conclusion, with a hedge that's appropriate: 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. This is a statement about a hypothetical, and Cloudflare presents it as one. It doesn't claim such a week has happened, or that one is coming.

Even so, the logic is easy to follow. A free, automated CA is only a resilience option if it exists before the emergency. Cloudflare's pitch is that it can supply a second one at scale. I'd argue that's the strongest commercial and technical reason in the announcement, and it doesn't depend on any of the more speculative parts of the plan. A web that has one dominant free CA and little else is a web with a single point of failure, whatever the quality of that CA's operations.

Dimension	Traditional Free Automated CA (Let's Encrypt)	Proposed Cloudflare Public CA
Trust Anchor Strategy	ISRG Root X1 / X2 (in-house roots established 2015+)	Acquired GlobalSign Root (trusted since 2012) + new root
Issuance Protocol	Standard ACME (RFC 8555)	ACME with mandatory ARI (RFC 9773) enforcement
Revocation Paradigm	CRL / OCSP + Emergency bulk subscriber replacement	Coordinated renewal advancement via ARI endpoints
Post-Quantum Path	Hybrid X.509 signatures under evaluation	Native Merkle Tree Certificates (MTCs) co-existing with classic X.509
Scale & Initial Workload	~10M certs/day across 500M+ sites	Customer Zero validation across 20%+ of global web traffic

Buying a root instead of waiting for one #

The most practical decision in the announcement concerns the root. Cloudflare says it signed a definitive agreement to acquire an established, broadly trusted root from GlobalSign. The source gives the reason directly: a brand-new root is not widely useful for years. The existing GlobalSign root, by contrast, has been trusted across browsers, operating systems and devices since 2012.

Root trust is slow because it's installed in devices, and devices update slowly. A new root can be accepted by every program and still fail to validate on an older phone or an embedded system. Acquiring a root that's already been in the field since 2012 sidesteps that wait, at least in the way the source frames it.

Cloudflare isn't abandoning the new-root route entirely. It will also submit a new root for inclusion in root key programs, which it describes as built for where the ecosystem is heading, including programs that are starting to cap how old a trusted root may be. That last detail is a useful reminder that age cuts both ways. A trusted root's age is an asset for device coverage, and some programs are moving towards limits on how old a trusted root may be. Running both an acquired root and a fresh submission looks like a response to that tension, though the source doesn't spell out the reasoning in those terms.

An ACME-first service with strings attached #

Adoption is where many CA announcements go vague. Cloudflare is specific. Its public CA will be ACME-first, which means it speaks the Automated Certificate Management Environment protocol that existing automation already uses. The claim is that anyone already pointed at an existing free CA can move to Cloudflare's CA by changing a directory URL, with no new tooling and nothing to re-architect. That's a plan, not a tested migration path, and it should be read as one. But a one-line configuration change is the right target, because migration cost is what keeps people on a default.

The catch is a requirement most ACME users haven't had to meet. Cloudflare will only issue to clients that support ACME Renewal Information, or ARI, which is standardised in RFC 9773. Subscribers must maintain automation that polls Cloudflare's renewal endpoint, acts on the renewal windows Cloudflare publishes, and identifies the certificate it is replacing.

This is a firm position, and I think it's the right one. It also raises a fair question about adoption: a CA that only serves ARI-capable clients is narrower than one that serves anyone with an ACME library. The source doesn't say how many clients that excludes today, so I won't guess. What it does say is why Cloudflare wants the constraint.

Revocation without breaking sites #

Cloudflare states it has observed things over the past 16 years, and one observation drives this design. It has seen certificate authorities caught between timely revocation and keeping subscribers' sites online.

That tension is real for any CA. Revoking a certificate quickly protects the public, but it can take down every site that depends on that certificate, if the subscriber can't replace it fast enough. A CA caught in the middle either revokes late or breaks customers.

ARI is Cloudflare's answer. When certificates need to be retired, Cloudflare says it can bring forward renewal windows for the affected certificates. Because subscribers are required to poll the renewal endpoint and act on the windows it publishes, the CA can steer them towards replacement before a hard revocation lands. This mechanism is described as a capability Cloudflare intends to have, not one it has demonstrated as a CA. Still, the logic holds together: the polling requirement exists so that this lever works.

The same thinking shows in a broader design goal. Cloudflare intends to build a certificate authority whose reliability depends not just on avoiding mistakes but, as with the rest of Cloudflare's products, on failing small and limiting the impact of any one issue. Avoiding mistakes is necessary for a CA, and no CA can promise it perfectly. Designing so that a mistake stays contained is the more honest engineering stance.

Transparency beyond the audit #

Public CAs are normally judged by audits. The source is blunt about their limits: audits are point-in-time and tell you a CA passed. They don't tell you what the CA is doing on an arbitrary Tuesday afterwards.

Cloudflare's response is to say it will publish reproducible builds of the software that signs certificates. That's framed as a commitment, not a finished deliverable. Reproducible builds let outsiders check that the binary running in the signing path corresponds to published source, which is a continuous property in a way an audit report isn't. Whether that proves sufficient will depend on what Cloudflare actually publishes, and on whether others check it.

The second half of the announcement: Merkle Tree Certificates #

The post-quantum material is where the announcement looks furthest ahead. Cloudflare announces plans to be one of the first CAs to serve postquantum certificates, and it plans to issue its first Merkle Tree Certificates in the first quarter of 2027. Another passage of the source says the first MTCs are expected in early 2027. Both are plans.

The source describes MTCs as a new and far more compact way to deliver publicly trusted certificates. That wording is a description, and the source doesn't supply measurements in the passages I'm working from, so I can't say how much more compact. Cloudflare says it has been championing the standards-based proposal for MTCs at the IETF. It also reports that Chrome named MTCs as the preferred path for post-quantum authentication earlier this year. That is a demonstrated event, and it matters, because a browser vendor's stated preference is what turns a proposal into something a CA can plan around.

Cloudflare doesn't expect the transition to be sudden. It expects much of the Internet to keep relying on classic certificates and the existing WebPKI for many more years. Across that window, it expects MTCs to take a steadily growing share of issuance. Those are expectations, and the source labels them as such.

One CA, one lifecycle #

The architectural choice that follows from this is the one I find most persuasive. The new CA is designed to carry classic certificates and Merkle Tree Certificates under one CA, with one lifecycle and one set of guarantees. Customers can then adopt at the pace that suits them and help the web make the crossing without a hard cutover.

The alternative is two parallel CAs, two sets of procedures, and a forced migration at some point. A hard cutover is the riskiest way to change a certificate ecosystem, and the source's stated aim is to avoid one. The wording is hedged, and rightly so: this is a design intent for a CA that doesn't yet issue.

It also fits the incentive picture. Cloudflare says it expects the number of certificates it relies on annually to keep growing as maximum validity periods decrease, agentic activity increases and post-quantum certificates go mainstream. More certificates, issued more often, argue for automation and for a CA that treats renewal as a first-class operation. A system built around ARI and one lifecycle is a reasonable response to that expectation, though the expectation itself is a forecast, not a measurement.

Customer Zero #

How do you test a CA before the public relies on it? Cloudflare's answer is to be its own first customer. It will be Customer Zero for the new CA and its certificates, both WebPKI and MTC. The stated purpose is to ensure that all aspects of the new systems and processes meet Cloudflare's high internal standards, and that the CA's infrastructure is exercised at Cloudflare scale.

Given the earlier figures, that's a demanding internal load: millions of certificates per year, across a company that sits in front of more than 20 percent of global request traffic. Whether the first years of operation go smoothly is something the claims can't tell us. What they do show is a sensible order of operations. The company starts as a heavy user of the thing it's building, with a history of multi-CA provisioning, backup paths, and 16 partner CAs behind it.

It's worth being plain about what's missing. Nothing in the source reports issuance volumes, error rates, validation latency or incident history for Cloudflare's own CA, because there's no such history yet. The announcement is a statement of intent supported by applications, an acquisition agreement and a design. It isn't a track record.

What to watch #

Three things will decide whether this is a meaningful addition to the WebPKI or merely an interesting announcement.

The first is the root programs. Cloudflare has applied to Chrome, Apple, Microsoft and Mozilla, and the processes are in the open. Watching them is the most direct way to see how far the plan has got, and the outcome isn't something any of the claims lets me predict.

The second is the ARI requirement. A CA that insists on RFC 9773 support is making a bet that renewal automation can be pushed forward across its subscriber base. If the bet is right, it gives Cloudflare the ability to bring renewal windows forward when certificates must be retired, which is the stated answer to the revocation dilemma it has seen. If it's wrong, adoption will be slower than the one-line migration story implies.

The third is the first quarter of 2027. That's when Cloudflare plans its first Merkle Tree Certificates. The open question is how quickly the steadily growing share it expects will actually grow, given its own view that much of the Internet will stay on classic certificates for many more years. The company has said the crossing shouldn't need a hard cutover. The first quarter of 2027 will be the first chance to see whether one CA carrying both certificate types can make that true.

What This Means by Sector #

The emergence of a high-volume, automated public certificate authority from an edge infrastructure provider alters operational risk and PKI planning across several technical domains.

Cloud infrastructure and edge networks #

Operating a public CA at edge scale reduces external dependency on third-party verification APIs and CRLs. By coupling reverse-proxy edge termination with automated ACME ARI renewals, infrastructure providers can insulate their customers against upstream certificate authority outages.

Enterprise PKI and DevOps teams #

Organisations relying on Let's Encrypt for public endpoints gain a credible, automated alternative. However, the mandatory enforcement of RFC 9773 (ARI) means teams must audit their ACME clients (Certbot, Lego, Caddy, Traefik) to ensure ARI support is active before switching directory endpoints.

Browser vendors and root governance #

Root programs (Chrome, Mozilla, Apple, Microsoft) face an expanding ecosystem of high-volume automated CAs. The dual-track root approach (acquiring a legacy 2012 root while submitting a modern root) navigates browser policies that increasingly restrict root certificate lifetimes while maintaining backward compatibility for legacy devices.

Conclusion #

Cloudflare's move to become a public certificate authority addresses a genuine structural vulnerability in the modern WebPKI: extreme concentration in free, automated certificate issuance. By combining an established GlobalSign root, strict ARI renewal automation, and a forward bridge to post-quantum Merkle Tree Certificates, the design tackles operational resilience rather than mere certificate provisioning. Success will be determined by root program approvals and how rapidly client tooling adopts ARI standards ahead of the 2027 rollout.

Questions? Answers.

Can I switch my ACME client to Cloudflare's CA today?

Not yet. Cloudflare has announced its intent, signed the root acquisition agreement, and submitted applications to the major root programs. Public issuance is slated for rollout following root program approvals.

What is ACME Renewal Information (ARI) and why does it matter?

ARI (RFC 9773) is an extension to the ACME protocol that allows certificate authorities to advise subscribers when a certificate should be renewed. This enables CAs to gracefully coordinate early renewals ahead of planned revocations, preventing site outages.

How do Merkle Tree Certificates (MTCs) differ from standard X.509 certificates?

MTCs replace traditional individual cryptographic signatures with Merkle inclusion proofs anchored in a publicly verifiable log. This significantly reduces certificate size and transmission overhead, making them a preferred candidate for post-quantum TLS authentication.

References #

Cloudflare, (2026). Building a Certificate Authority for the Whole Internet ⧉. Cloudflare Blog.
IETF, (2024). RFC 9773: Automated Certificate Management Environment (ACME) Renewal Information (ARI) ⧉. IETF.
IETF, (2025). Merkle Tree Certificates for TLS ⧉. IETF.
Chrome Root Program, (2026). Policy and Considerations on Post-Quantum Authentication ⧉. Chromium Projects.

Последняя проверка 2026-09-20.

Последняя проверка 2026-10-16.

Опубликовать заново

Cloudflare Wants to Issue Its Own Certificates, and Its Plan Rests on a Free-CA Concentration Problem — Sebastien Rousseau

Cloudflare has announced its intent to become a public certificate authority. It has applied to the Chrome, Apple, Microsoft and Mozilla root programs and signed a definitive agreement to acquire...

Эта статья распространяется по лицензии Creative Commons Attribution 4.0 International. При повторной публикации требуется указание канонической ссылки.

Cloudflare Wants to Issue Its Own Certificates, and Its Plan Rests on a Free-CA Concentration Problem — Sebastien Rousseau

Cloudflare has announced its intent to become a public certificate authority. It has applied to the Chrome, Apple, Microsoft and Mozilla root programs and signed a definitive agreement to acquire...

Originally published at https://sebastienrousseau.com/ru/2026-09-20-cloudflare-wants-to-issue-its-own/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER