Skip to content

SYSTEM Cited by 2 sources

Cloudflare Certificate Authority

What

The Cloudflare Certificate Authority is Cloudflare's announced intent (Birthday Week 2026) to become a public, publicly-trusted certificate authority — the issuance side of the Web PKI, beneath the free TLS it turned on for the web with Universal SSL in 2014. For more than a decade Cloudflare has been one of the largest consumers of publicly-trusted certificates (issuing none itself); this reverses that.

As of the September 2026 announcement, no certificates are being issued yet. The concrete first milestones are:

  • Applied for inclusion in the Chrome, Apple, Microsoft, and Mozilla root programs.
  • Signed a definitive agreement to acquire an established, broadly trusted root from GlobalSign (trusted since 2012) for maximum device reach on day one.
  • Committed to being one of the first CAs to issue production Merkle Tree Certificates (MTCs), first certs targeted for Q1 2027, targeting Chrome's Quantum-resistant Root Program.

(Source: sources/2026-09-29-cloudflare-building-a-certificate-authority-for-the-whole-internet)

Two paths to trust (the root strategy)

A brand-new root is not widely useful for years: even after a root program accepts it, it must propagate into the world's OSes, browsers, and devices — and it never reaches the long tail of clients that stopped receiving updates or never got them. That long tail carries a large share of Internet traffic and a correspondingly large set of avoidable breakage. Cloudflare therefore runs two roots in parallel:

Root Property Purpose
Acquired GlobalSign root Trusted across browsers/OSes/devices since 2012 Reach across the devices of the past — old clients a fresh root never reaches
New submitted roots Built for where the ecosystem is heading, incl. programs that cap how old a trusted root may be Standing under the policies of the future

"The established root gives us reach across the devices of the past. The new roots give us standing under the policies of the future."

Why a redundant free CA

The free, automated certificate model now carries most of the encrypted web, and much of it runs through one operator: Let's Encrypt issues ~10 M certs/day, serves >500 M sites, and passed 4 B active certificates in 2025. That concentration is systemic risk: if the dominant free CA "had a bad week," much of the web would have no comparable free automated alternative ready to take the load.

Cloudflare frames a public CA as the Internet-scale version of the backup-certificate design it already ships: every Universal SSL cert already ships with a backup cert wrapped with a separate key and issued from a different authority, ready to deploy automatically if the primary is revoked or compromised. A public CA generalises that redundancy from one customer's cert pack to the whole ecosystem, and adds providers to the certificate supply chain (Cloudflare itself provisions through multiple CAs with primary + backup paths so customer services stay up through CA outages and revocation events). See concepts/blast-radius.

ACME-first (migration by directory-URL change)

Issuance and renewal are ACME-first (RFC 8555): "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." This is the zero-friction on-ramp that makes a second free CA a drop-in redundancy option rather than a migration project.

Renewal automation as a condition of issuance (ARI / RFC 9773)

The CA will only issue to clients that support ACME Renewal Information (ARI), standardized in RFC 9773. Subscribers must maintain automation that:

  • polls the CA's renewal endpoint,
  • acts on the renewal windows the CA publishes, and
  • identifies the certificate it is replacing.

This makes renewal automation a precondition, not a best-effort. It directly attacks the classic CA bind observed over 16 years — the tension between timely revocation and keeping subscribers online when too many subscribers cannot replace certificates quickly enough. Because every subscriber is ARI-automated, when certs must be retired (compliance or security incident) Cloudflare can bring renewal windows forward for the affected certs, spread replacements across the available time, and track replacement issuance — turning a disruptive mass revocation into a scheduled, observable roll. This is the "fail small" principle (concepts/blast-radius) applied to the revocation problem.

Designing for resilience: transparency and "fail small"

The stated goal is a CA whose reliability depends not just on avoiding mistakes but — like the rest of Cloudflare's products — on "failing small": limiting the impact of any one issue, and designing/testing recovery before an incident. Transparency commitments:

  • Reproducible builds of the software that signs certificates.
  • Attested hardware security modules (HSMs) holding the keys (see concepts/remote-attestation).
  • A public dashboard for issuance health and incidents.

Framing: "Audits are point-in-time and tell you a CA passed, not how it runs on an ordinary Tuesday." The intent is to let root programs, researchers, and site owners watch how a modern CA operates between audits — not just at audit checkpoints.

A CA for the post-quantum Internet (classic + MTC under one lifecycle)

Cloudflare plans to be one of the first CAs to issue production Merkle Tree Certificates (first certs Q1 2027). MTCs are a compact way to deliver publicly-trusted certificates for a post-quantum world where traditional chains grow large enough to strain TLS handshakes; Chrome named MTCs the preferred path for post-quantum authentication.

The design decision that matters: one service carries both classic certificates and MTCs, under one lifecycle and one set of guarantees. The transition is expected to be gradual (much of the Internet will rely on classic certs + existing Web PKI for years), so customers "should not have to pick a side of a multi-decade migration, run two systems, or rebuild when the balance shifts." See concepts/post-quantum-authentication.

The MTC issuance + mirroring stack (2026-09-29 deep dive)

The companion deep dive details how the CA issues MTCs. In the MTC ecosystem the CA's responsibilities barely change (validate domain control, bind domain to public key, issue) — but instead of signing certs and then logging them, the CA maintains a transparency log backed by a Merkle tree, and an inclusion proof that the cert is in the tree is the trust anchor ("issue by logging").

Two software components:

  • Issuance — a fork of Boulder. Cloudflare's ACME infrastructure forks Boulder (the well-tested software powering Let's Encrypt, which is actively developing MTC support), maintaining a fork with Cloudflare-specific changes and contributing back upstream. Boulder handles the ACME request + domain-control validation, then appends the validated entry to the CA's issuance log.
  • Mirroring — Azul. After appending an entry, the CA computes the updated log state, signs a checkpoint over it, and sends state + checkpoint to a mirroring cosigner (Cloudflare's Azul, via c2sp's tlog-mirror protocol). The cosigner durably stores a copy, verifies the new state is append-only + consistent + correctly formed, and returns a cosignature — an independent attestation that the CA is not presenting different log views to different parts of the ecosystem, and a guarantee that certs stay monitorable even if the CA's log is down. Chrome's Quantum-resistant Root Program draft mandates ≥2 cosignatures (one from a distinct-org mirror + one from the issuing CA). Cloudflare will also operate Azul-based mirrors for other pilot CAs.

Two certificate forms (both X.509-encoded): standalone (signature value = cosigned tree head + inclusion proof; still ships a heavyweight PQ signature) and landmark-relative (signature value = only the inclusion proof, no PQ signature — clients get the cosigned tree heads / landmarks out-of-band via a browser update service). Servers must retain a standalone fallback for clients that are new, offline, or missing the relevant landmark.

Validated by experiment: a bootstrap CA served billions of MTCs (backed by a classical chain) to 50% of Chrome Beta 146; a landmark-relative handshake transmits one public key + one signature + one inclusion proof (<1 kB), and measured 9% faster median vs a classical chain (mostly intermediate elision) — expected to widen with PQ signatures. Cloudflare also runs the Nimbus CT logs (since 2016) and is launching Raio static CT logs on the same Azul software.

Customer Zero

Cloudflare already consumes certs from many CAs to run its own systems; it will be Customer Zero for the new CA (both WebPKI and MTC), ensuring the infrastructure is exercised at Cloudflare scale before customers depend on it — the same dogfooding posture behind its other launches.

Operational numbers

  • >20 % of global Internet request traffic sits behind Cloudflare; it terminates TLS for millions of domains and relies on millions of certificates per year via multiple CAs (primary + backup).
  • Redundancy motivation — Let's Encrypt: ~10 M certs/day, >500 M sites, 4 B active certs (2025).
  • GlobalSign root trusted since 2012.
  • First production MTCs: Q1 2027.
  • 16 partner public CAs retained through the transition.

Raw-scope caveats

This page is scoped to the September 2026 announcement of intent:

  • Root-program inclusion is applied for, not granted; the GlobalSign acquisition is a definitive agreement, not yet realised trust-store reach.
  • Protocol/operational internals — MTC batch sizes and root-distribution cadence, exact ARI window semantics, the HSM attestation scheme, the public-dashboard design — are not detailed in the post; they live in the IETF MTC draft, RFC 9773, and Cloudflare's separate pq-ca-with-mtcs post.

Seen in

Last updated · 766 distilled / 2,225 read