Cloudflare Is Becoming a Certificate Authority

What Cloudflare actually announced

Cloudflare stated an intent to become a publicly trusted certificate authority: a service that issues the certificates any website needs to prove its identity to a browser, open to the whole Internet rather than to Cloudflare customers. Two things make the announcement concrete rather than aspirational. It has agreed to buy root CA key material from GlobalSign, and it has filed applications with the four root programs that decide what browsers trust.

Read carefully, the announcement contains two projects that share a press release and very little else. One is an ordinary automated CA issuing the kind of certificate your server already understands. The other is a research-grade redesign of what a certificate even is, aimed at the post-quantum problem, and it arrives later and depends on software that has not shipped yet. Most of the coverage merged them into a single headline about quantum safety, which makes the timeline harder to read than it needs to be.

There is one detail worth pausing on, because it shapes everything downstream. Cloudflare is buying key material, not the company. GlobalSign continues to operate. What changes hands is the cryptographic anchor that millions of shipped devices already trust, which is the single asset a new CA cannot manufacture at any speed.

Why buy a root instead of growing one

A brand new root certificate is worth very little on the day it is created, because trust in the web PKI lives in software that already shipped. Getting a root into browsers requires annual WebTrust or ETSI audits, a published certificate practice statement, and for Mozilla a public discussion period where anyone may object on the record. Industry guidance commonly puts broad browser inclusion at two to three years after that process begins, and the long tail of phones, set-top boxes, payment terminals and embedded systems that never receive a trust store update stretches far beyond it.

This is the reason cross-signing exists, and the reason root ubiquity is something CAs advertise. An acquired root sidesteps the part of the wait that no amount of engineering effort shortens: the replacement cycle of the world’s installed hardware. It does not sidestep the audits, and it does not sidestep root program scrutiny, which is why Cloudflare has still applied to all four programs and why issuance still waits on their acceptance.

For anyone reading the announcement to decide whether it matters, that single line about GlobalSign is the one that moves the date forward. Without it, a Cloudflare CA would be a 2030s story.

What Merkle Tree Certificates solve

Merkle Tree Certificates replace the per-certificate signature with a proof of membership. Rather than signing every certificate and having the browser verify that signature on every connection, the CA batches certificates into an append-only Merkle tree and periodically signs a checkpoint covering the tree root. Independent cosigners, described in the draft as witnesses and mirrors, verify the log stays consistent and countersign the checkpoint. Your server then presents a short chain of hashes proving its certificate is inside a tree the client already trusts.

The motivation is size, and it is severe. ML-DSA-65, the post-quantum signature scheme most likely to be used here, produces signatures of about 3,309 bytes with public keys of about 1,952 bytes. Published analysis of the IETF draft puts the per-handshake authentication overhead of a full post-quantum chain, once certificate transparency timestamps are counted, at over 13,000 bytes, against roughly 256 bytes for classical Ed25519. An inclusion proof lands near 736 bytes and, critically, does not grow when the signature scheme does.

There is a second pressure behind the design. Certificate transparency logs have to store everything that gets issued, and post-quantum signatures are projected to multiply the volume those logs carry by a large factor, which changes the economics for the organisations that run them. Batching addresses both problems with the same mechanism.

The catch is client support. An inclusion proof is only checkable by software that understands Merkle Tree Certificates, and the specification is still an IETF draft. A server will therefore serve an MTC to clients that speak it and a conventional certificate to everything else, which means running both for years rather than migrating between them. This is also not a Cloudflare-only effort: Let’s Encrypt named MTCs as its own post-quantum direction in June 2026, with production readiness indicated for 2027.

When you can actually use it

Not yet, and the announcement is unusually clear about the sequence. The GlobalSign acquisition is expected to close within roughly two months of September 29, 2026, subject to customary closing conditions. Classical certificate issuance begins after Cloudflare completes the browser root program application and acceptance process, and no public date has been attached to that milestone. Production issuance of Merkle Tree Certificates is targeted for the first quarter of 2027.

When issuance does open, the integration cost looks small. Cloudflare has said that automated issuance and renewal through ACME will be the way certificates are obtained, and that anyone already pointed at an existing free CA can move by changing a directory URL, with no new tooling. If you run Certbot, acme.sh, Caddy, cert-manager or any other ACME client, that is a one-line configuration change rather than a migration.

Pricing has not been published. Cloudflare has given TLS away at its edge for years and the ACME framing points the same way, but a free DV tier is an expectation here rather than a commitment, and it is worth treating as such until terms appear.

What it changes for free certificates

The practical effect is a third large ACME-native CA alongside Let’s Encrypt and Google Trust Services, which matters less for price than for resilience. Cloudflare already leans on Let’s Encrypt and Google Trust Services for the certificates it issues at its own edge, so the announcement also reads as a large operator deciding it would rather not depend on someone else for a component that critical.

Site operators get the same benefit in smaller form. When several CAs speak one protocol and a switch is a directory URL, an outage, a policy change or a mass revocation event at any one of them stops being an emergency. That is a genuine improvement, and it is worth separating from the quantum headline, which will not affect a normal website for years.

What it does not do is change the shape of what a free, automated CA offers. Domain validation is what an ACME challenge can prove: control of a hostname, checked by machine, in seconds. Everything that requires a person to read a company registration document sits outside it.

What it does not change

Nothing in the announcement touches organization validation or extended validation, and the design points away from both. Everything described is automated and domain-validated, and Merkle Tree Certificates in particular have no place today for the vetted organisation identity that an OV or EV certificate carries in its subject. If your requirement is a certificate that names your legal entity, because a procurement questionnaire, a regulator or a payment scheme asks for it, this changes nothing about how you meet it. My-SSL issues those through Certum, and the difference between OV and EV vetting is worth understanding before you assume a free DV certificate covers the requirement.

Code signing, S/MIME and document signing are separate ecosystems with their own baseline requirements and their own root programs, and none of them appear in this announcement. A post-quantum web PKI does not imply a post-quantum code signing PKI arriving on the same schedule.

Certificate lifetimes keep contracting on the CA/Browser Forum schedule regardless of who issues them, and revocation, monitoring and the rest of the lifecycle behave exactly as they did last week. A new CA changes where a certificate comes from, not what you owe it afterwards.

What to do about it now

For almost every site the correct action today is none. No certificate changes, no root is being distrusted, and no browser behaviour shifts because of this. The announcement is worth filing rather than acting on.

The one piece of preparation that pays off either way is ACME automation, and it pays off for reasons that have nothing to do with Cloudflare. Shrinking certificate lifetimes already make manual renewal untenable, and an ACME client is what turns both a shorter lifetime and any future CA change into a configuration edit. If you are still renewing by hand, that is the work worth starting, and a single --server flag is the whole cost of switching CA later.

If you buy OV or EV certificates, or you sign code or email, this announcement is not about you. Read it as a signal about where the free DV tier and the post-quantum transition are heading, and check back when root program acceptance is actually granted, because that is the event that turns any of this into something you can use.

FAQ