Skip to content

CLOUDFLARE 2026-09-29 Tier 1

Read original ↗

Building a certificate authority for the whole Internet

Summary

For Birthday Week 2026, Cloudflare announced its intent to become a public certificate authority (CA) — the trust layer beneath the free TLS it turned on for the whole web with Universal SSL in 2014. After a decade as one of the largest consumers of publicly-trusted certificates (issuing none of its own), Cloudflare is now building the issuance side. The first concrete milestones: it has applied for inclusion in the Chrome, Apple, Microsoft, and Mozilla root programs, and signed a definitive agreement to acquire an established, broadly trusted root from GlobalSign so it can offer certificates with maximum device reach on day one. The CA will be ACME-first (change a directory URL, no re-architecting), will make renewal automation a condition of issuance (ARI / RFC 9773 required), is designed to "fail small" with transparency and reproducible builds, and plans to be one of the first CAs to issue production Merkle Tree Certificates (MTCs) for the post-quantum Internet, targeting Q1 2027. No certificates are being issued yet.

Key takeaways

  1. Two paths to trust, run in parallel. A brand-new root is useless for years — even after a root program accepts it, it must propagate into OSes/browsers/devices and never reaches the long tail of clients that stopped receiving updates. Cloudflare therefore acquires an existing GlobalSign root (trusted since 2012, reaches old clients a fresh root never will) and submits new roots built for where the ecosystem is heading (including programs that 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." (Source: sources/2026-09-29-cloudflare-building-a-certificate-authority-for-the-whole-internet)
  2. Redundancy for the free-CA layer of the whole Internet. Let's Encrypt issues ~10 million certs/day, serves >500 million sites, and passed 4 billion active certificates in 2025 — 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. This is the free-TLS posture carried one layer down, and a scale-up of the backup-certificate design Cloudflare already ships: every Universal SSL cert 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.
  3. ACME-first for zero-friction migration. Automated issuance and renewal via ACME is the way to get a cert from Cloudflare — "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."
  4. Renewal automation as a condition of issuance (ARI / RFC 9773). Cloudflare will only issue to clients that support ACME Renewal Information (ARI). Subscribers must maintain automation that polls the renewal endpoint, acts on published renewal windows, and identifies the certificate it is replacing. This is the "fail small" design applied to revocation: when certs must be retired (compliance or security), Cloudflare can bring renewal windows forward for the affected certs, spread replacements across available time, and track replacement issuance — instead of the classic CA bind of timely revocation vs. keeping subscribers online when too many subscribers can't replace certs fast enough.
  5. Designing for resilience: transparency + "fail small." Rather than only avoiding mistakes, the CA is built to limit the impact of any one issue, with recovery designed and tested before incidents. Concrete transparency commitments: reproducible builds of the signing software, attested hardware security modules (HSMs) holding keys, and 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" — root programs, researchers, and site owners should watch how a modern CA operates between audits.
  6. A CA for the post-quantum Internet — Merkle Tree Certificates. Cloudflare plans to be one of the first CAs to issue production MTCs, first certs in Q1 2027. MTCs are a far more 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. Crucially, one service carries both classic certs and MTCs, under one lifecycle and one set of guarantees — customers should not have to "pick a side of a multi-decade migration, run two systems, or rebuild when the balance shifts."
  7. Cloudflare as 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), so the infrastructure is exercised at Cloudflare scale before customers rely on it.
  8. Growth is the forcing function. As certificate maximum validity periods shrink (CA/Browser Forum ballot SC-081v3), agentic activity increases, and PQ certs go mainstream, the raw number of certificates relied on annually will grow quickly — motivating both more issuance capacity and more providers in the supply chain. Cloudflare will keep working with its network of 16 partner public CAs through the transition.

Operational numbers

  • Let's Encrypt scale (the redundancy motivation): ~10 M certs/day;

    500 M sites; passed 4 B active certificates in 2025.

  • Cloudflare footprint: sits in front of >20 % of global Internet request traffic; terminates TLS for millions of domains; relies on millions of certificates per year, provisioned through multiple CAs with primary + backup paths.
  • GlobalSign root: trusted across browsers/OSes/devices since 2012.
  • MTC milestone: first production Merkle Tree Certificates in Q1 2027.
  • Partner CAs retained through the transition: 16.
  • 16 years of observed CA behaviour (revocation-vs-uptime binds, CA churn) informs the design.

Systems / concepts / patterns extracted

Caveats

  • This is an announcement of intent, not a running system. No certificates are being issued yet; root-program inclusion is applied for, not granted; the GlobalSign root acquisition is a definitive agreement, not completed reach in trust stores.
  • Protocol/operational internals are out of scope of the post. MTC batch sizes, root-distribution cadence, ARI window semantics, the precise HSM attestation scheme, and the public-dashboard design are not detailed here — they live in the linked IETF MTC draft, RFC 9773, and Cloudflare's separate PQ-CA-with-MTCs post.
  • Dates are targets. Q1 2027 for first MTCs; root-program timelines are external and out of Cloudflare's control ("these processes happen in the open").

Source

Last updated · 766 distilled / 2,225 read