Cloudflare wants to be a CA, starting with someone else's root
Somewhere in your monitoring config there's a rule that trusts a name. Maybe it alerts when a certificate's issuer stops saying "Let's Encrypt". Maybe a compliance script greps for "GlobalSign" and stamps the result approved. Names feel stable. They aren't.
On September 29, Cloudflare announced it intends to become a public certificate authority. Another free ACME CA is welcome news, but the bit that should get your attention is how they plan to be trusted on day one. They're buying an existing, broadly trusted root from GlobalSign. Once that deal closes, certificates issued by Cloudflare can chain to a root whose subject line was written by a different company more than a decade ago.
Nobody did anything shady here. The WebPKI has always worked like this. It still breaks an assumption a lot of tooling quietly depends on, and it starts a clock most people won't notice until it runs out.
What was actually announced on September 29
Cloudflare has applied to the Chrome, Apple, Microsoft and Mozilla root programs. It has signed a definitive agreement to acquire root CA key material from GlobalSign, a root it describes as "trusted across browsers, operating systems, and devices since 2012". According to the press release, the deal should close within two months, subject to customary closing conditions.
Nothing is being issued yet. Classical certificates come once the root program applications are accepted, and there's no date for that. Production Merkle Tree Certificates are targeted for the first quarter of 2027. If MTCs are new to you, we wrote in August about why post-quantum certificates break the handshake.
Two operational details matter more than the headline. The CA will be ACME-first. And it will only issue to clients that support ACME Renewal Information (RFC 9773) and say which certificate they're replacing. Hold that thought, because it collides with the "just change your directory URL" pitch further down.
Cloudflare hasn't said which GlobalSign root it's buying. I'm not going to guess.
Buying a root is older than you think
Half the Hacker News thread reacted as if Cloudflare had found a loophole. It's the standard playbook.
In January 2017 Google launched Google Trust Services and, in its own words, "purchased two existing Root Certificate Authorities, GlobalSign R2 and R4." The reason was the one Cloudflare gives now. A brand-new root takes years to reach enough trust stores, and it never reaches the phones and set-top boxes that stopped getting updates. Let's Encrypt solved the same problem with an IdenTrust cross-sign.
So the move itself is boring. The consequences are where it gets interesting.
The name on a root certificate never changes
Grab Google's copy of that old GlobalSign root and read the subject:
curl -s https://pki.goog/repo/certs/gsr4.pem \
| openssl x509 -noout -subject -startdate
# subject=OU = GlobalSign ECC Root CA - R4, O = GlobalSign, CN = GlobalSign
# notBefore=Nov 13 00:00:00 2012 GMT
Google has run that key for years. The certificate still says GlobalSign, because you can't edit a root's subject without minting a new certificate, and a new certificate means going back through every trust store on the planet. Your Debian box ships it as GlobalSign_ECC_Root_CA_-_R4.pem.
Chains get muddier. Connect to www.google.com today and the server hands you GTS Root R1 as a cross-certificate issued by GlobalSign Root CA:
echo | openssl s_client -connect www.google.com:443 \
-servername www.google.com -showcerts 2>/dev/null \
| grep -E '^ *[0-9] s:|^ *i:'
A modern client stops at GTS Root R1 in its own store. An old one follows the cross-sign up to GlobalSign. One leaf, two trust anchors, and the company name you see depends on who's asking. For the long version of how a client picks between paths, see what actually happens during chain validation.
Expect Cloudflare chains to look like this too. A certificate from a Cloudflare intermediate may well end at a root that says GlobalSign. Any rule that reads the root's name and decides who operates it will get that wrong.
Trust isn't transferable, and the root programs say so
The other HN worry was that anyone with enough money can buy their way into your trust store. The root programs thought of that.
The Chrome Root Program Policy, version 1.8, dated February 5, 2026, is blunt about it in section 1.6.2: participants "MUST NOT assume trust is transferable." A sale or change of ownership needs at least 30 calendar days' notice, and Chrome keeps the right to make the new owner re-apply.
Mozilla's Root Store Policy goes further. Version 3.1, effective July 1, 2026, says in section 8.1 that Mozilla will weigh, among other things, "whether the acquiring entity has experience operating publicly trusted CAs". If a transaction introduces new or increased risk, a public discussion is mandatory. Section 8.2 leaves the seller responsible for the private key until an auditor confirms the transfer, and the buyer can't issue until its audits and CP/CPS are in place.
Cloudflare has never run a public CA. Read that criterion once more. My bet is this one gets a public discussion on Mozilla's dev-security-policy list.
A 2012 root comes with a 2029 deadline
Now the part with a date on it. Chrome and Mozilla both cap root age at 15 years from key generation for server authentication. Chrome takes the earlier of two dates: the auditor's key generation report, or the oldest certificate that contains the key.
Roots older than the rule get a phase-in schedule, and on this point the two programs agree to the day. Key material created between 2010 and 2011 loses trust around April 15, 2028. Key material from 2012 up to April 14, 2014 goes on April 15, 2029. Anything newer gets the plain 15 years. Chrome may let a root run past its date case by case, but only if the owner submitted a replacement at least a year earlier.
So if the acquired root's key was generated in 2012, Chrome and Firefox drop it around April 2029. Earlier key, earlier date.
Cloudflare can't apply with an old root either. Both programs now only take inclusion requests for root keys generated in the last five years. Hence the two tracks. The bought root covers the long tail of unpatched devices, which will never see a policy change anyway. The new root carries modern browsers once it's accepted. Cloudflare says as much: its new roots are built for "the programs that are starting to cap how old a trusted root may be."
What that means for you: a Cloudflare chain will probably change shape at least once in its first few years. When chains change shape, pinned keys stop matching and clients with stale CA bundles fall over. Hard-coded intermediates go first. The 512-bit CA key story from September is a good reminder of what old roots in forgotten stores get up to. Put April 2029 in a calendar now.
Track the key that signed it
An inventory that stores the issuer's organisation name and nothing else is going to lie to you. Store the Authority Key Identifier as well. The AKI points at the exact key that signed the certificate, and it doesn't care who bought what.
#!/usr/bin/env bash
# Print host, issuing CA organisation and the AKI of the leaf.
while read -r host; do
cert=$(echo | timeout 10 openssl s_client -connect "$host:443" \
-servername "$host" 2>/dev/null | openssl x509 2>/dev/null) || continue
issuer=$(openssl x509 -noout -issuer -nameopt multiline <<<"$cert" \
| awk -F' = ' '/organizationName/ {print $2}')
aki=$(openssl x509 -noout -ext authorityKeyIdentifier <<<"$cert" \
| tail -n1 | tr -d ' ')
printf '%-28s %-28s %s\n' "$host" "$issuer" "$aki"
done < hosts.txt
Feed it a hosts.txt with one hostname per line. The -ext flag needs OpenSSL 3.0 or later. Group the output by AKI and you get an honest map of which intermediates your estate actually depends on. The organisation column is a hint. Treat it like one. And if your inventory today is a spreadsheet, you probably don't know how many certificates you have, so this is a cheap place to start.
Then go hunting for every alert and allowlist that matches on a CA's organisation string. You'll find more than you expect.
Switching CAs takes more than a directory URL
Cloudflare's pitch is that anyone on a free CA "can move to us by changing a directory URL, with no new tooling and nothing to re-architect." A few paragraphs later it says it'll only issue to clients that support ARI. One HN commenter called that a contradiction. That's a bit harsh, but it's close enough to matter.
Start with ARI. Your client has to poll the renewal endpoint and send the replaces field when it renews. certbot got ARI in 4.1.0. cert-manager still needs the ACMEUseARI feature gate switched on. We covered both in the ARI renewal window post and the cert-manager 1.21 upgrade notes. Anything older or homegrown, assume it doesn't.
Then CAA. Cloudflare hasn't published the CAA identifier its CA will use, so there's nothing to add yet. When it does, you need a new issue line, and if you've pinned issuance to an ACME account, a new accounturi as well.
Then the boring stuff that bites anyway. A new CA means a new account key to protect, new rate limits, and challenge quirks you'll meet for the first time either on a quiet Tuesday or in the middle of an outage. Pick Tuesday.
If you proxy through Cloudflare, look at your CAA records now. Per Cloudflare's docs, once Universal SSL is on and you add any CAA record yourself, Cloudflare quietly adds issue and issuewild entries for pki.goog, letsencrypt.org, ssl.com and sectigo.com. It doesn't do that for Advanced Certificate Manager. You should know which of those lines you wrote and which ones Cloudflare wrote for you.
dig +short CAA example.com
I'm all for a second big free CA. Depending on exactly one was always the real risk, which is the argument we made in the Let's Encrypt sanctions clause post. But a backup CA you've never actually issued from is a theory. Cloudflare won't be the last CA to make ARI mandatory, either, so the client upgrade is worth doing whether you ever switch or not.
Frequently asked questions
Will my existing GlobalSign certificates be affected by the sale? Cloudflare is acquiring root key material and hasn't said which root it is, so nothing in the announcement touches GlobalSign's customers directly. The useful question for your GlobalSign contact is which root your chain ends in and whether that root is part of the transaction.
When can I actually get a certificate from Cloudflare's CA? There's no date for classical certificates. Cloudflare says issuance starts after the root program applications are accepted, and those reviews take time. Production Merkle Tree Certificates are targeted for the first quarter of 2027, but MTCs need client support that ordinary servers and libraries don't have yet.
Do I need to add Cloudflare to my CAA record now? No. Cloudflare hasn't published the identifier its CA will use in CAA, and a guessed value does nothing useful. If you use Cloudflare's proxy with Universal SSL and already have CAA records, Cloudflare manages entries for its current partner CAs automatically, so check what's there today before anything changes.
Why does a root's key age matter if the root certificate is valid until 2038? Because browsers no longer go by the root certificate's own expiry date. Chrome and Mozilla remove server-authentication trust once the key material is 15 years old, on a phase-in schedule for older roots, so a root with key material from 2012 loses that trust around April 15, 2029 whatever its notAfter says.
