Cloudflare plans its own CA: what SSL owners should know

Short answer: you do not need to change anything on your site because Cloudflare wants to become a certificate authority. The plan is announced, not approved, and the post-quantum certificate format it depends on is still a draft at the IETF.

Here is the part that caught my eye. On 29 September 2026, Cloudflare said it intends to become a public certificate authority (a company whose certificates browsers trust by default), and that it has agreed to acquire publicly trusted root CA key material from GlobalSign. In the same breath it said production issuance of a brand new certificate type, Merkle Tree Certificates, is scheduled for Q1 2027.

That is a lot of news in one press release, and some of it will reach your inbox as sales pitches. By the end of this post you will know which parts are announced, which parts are standardised, what actually changes for a small site, and one quick check you can run today to see who issues your current certificate.

What happened

Let me lay out the facts in order, with the source for each one. Everything below is from pages I opened at the time of writing (5 November 2026).

The announcement

Cloudflare published a press release dated 29 September 2026. Cloudflare says it intends to become a public certificate authority, usually shortened to CA. A CA is the organisation that signs your SSL certificate so browsers can check that your site is really yours.

Cloudflare says its CA will issue two kinds of certificates. The first is classic TLS certificates, the normal kind your site uses today. The second is Merkle Tree Certificates, often shortened to MTCs, which are designed for a post-quantum world.

The GlobalSign deal

Cloudflare says it has agreed to acquire publicly trusted root CA key material from GlobalSign. A root is the top of the trust chain, the key that browsers already store and trust. Cloudflare says the deal is expected to close in the next two months, subject to customary closing conditions.

Why this matters: Cloudflare says a root certificate is what tells browsers and devices whether to trust a CA, and that its acquisition and pending root program applications are designed to give its certificates broad recognition as quickly as possible. That is a stated goal, not a result. Owning key material is a different thing from being accepted as a CA by the browser makers, which is the next point.

Root program applications are pending

Every major browser and operating system runs a root program, which is its list of CAs it trusts and the rules they must follow. Cloudflare says it has applied to the Chrome, Apple, Microsoft and Mozilla root programs. The press release describes these as applications. It does not report any approval.

Cloudflare also says classic certificate issuance will begin only after the browser root program application and acceptance process is complete. No date is given for that.

Heads up: I am not saying Cloudflare certificates are or will be trusted by browsers. At the time of writing (5 November 2026), the applications are pending, and only the root programs can decide.

The post-quantum timeline

Cloudflare says production issuance of Merkle Tree Certificates is scheduled to begin in Q1 2027. The release gives no general availability date. Cloudflare also says its plan is to give every website a path to stay protected with no new tools or rebuilds required, and to make the transition without forcing immediate cutovers.

Remember this is a vendor press release. When I write "Cloudflare says", that is exactly what I mean: it is a company stating its plans, not a standards body or a browser confirming them.

What a Merkle Tree Certificate actually is

Here is the plain version. Every public certificate today is recorded in Certificate Transparency logs, which are public, append-only lists of issued certificates. Anyone can read them, so a wrongly issued certificate for your domain is hard to hide.

Logging has a cost. Each certificate and each log proof carries signatures, and post-quantum signatures are much bigger than the ones we use now. The MTC draft gives an example: ML-DSA-44, a post-quantum signature algorithm, uses 1,312 bytes per public key and 2,420 bytes per signature.

Think of it like stamping every page of a book with a large wax seal. It works, but the book gets heavy. A Merkle tree is a way to seal the whole book once and prove any single page belongs to it with a short receipt.

The IETF draft says it the formal way. Its abstract describes MTCs as a new form of X.509 certificate "which integrate public logging of the certificate, in the style of Certificate Transparency". It says this integrated design reduces logging overhead in the face of both shorter-lived certificates and large post-quantum signature algorithms. That quote is from revision 04 of the draft, an older version dated 24 May 2026; the current revision repeats the same idea.

Where the standard stands

The draft is called draft-ietf-plants-merkle-tree-certs. It belongs to the IETF PLANTS working group (PKI, Logs, And Tree Signatures). At the time of writing (5 November 2026), the IETF Datatracker lists revision 08, dated 2 November 2026, as an active Internet-Draft with intended status Standards Track.

An Internet-Draft is a work in progress. It is not an RFC, which is the published, numbered standard. Drafts change between revisions, and this one has already changed several times this year. So a product built on MTCs in Q1 2027 would be built on a specification that may still be moving.

What it means for you

For most small sites and agencies, almost nothing changes this month. But a few real effects are worth knowing about, because they connect to changes that are already scheduled.

Your current certificate keeps working

Whatever CA issues your certificate today, this announcement does not touch it. Your host or Cloudflare dashboard keeps renewing it the way it already does. There is no new setting to enable.

Shorter certificate lifetimes are the real deadline

The change that will actually affect your renewals is lifetimes, and it comes from CAs you may already use. At the time of writing (5 November 2026), Let's Encrypt says its certificate lifetime will drop to 64 days on 10 February 2027 and to 45 days on 16 February 2028.

Let's Encrypt also offers profiles, which are named sets of certificate settings an ACME client can ask for. ACME is the protocol your host or tool uses to request and renew certificates automatically. Its profiles page lists classic at 90 days (the default), tlsserver at 45 days, and shortlived at 160 hours, which Let's Encrypt describes as about six days. The same page notes that availability of profiles can vary and may be limited to an allowlist.

Why this matters: the shorter the lifetime, the less room you have if renewal silently breaks. MTCs are designed partly because of this trend, which is why the draft talks about shorter-lived certificates. If you want the wider picture, I covered it in why SSL certificates now expire faster, and the hands-on side in checking your renewals before Let's Encrypt moves to 64 days.

Renewal information becomes more useful

RFC 9773, published in June 2025, defines ACME Renewal Information, usually called ARI. It lets an ACME server suggest to clients when they should renew. The RFC says this helps servers mitigate load spikes and stops clients from making false assumptions about the right renewal period. Its own example: a CA could suggest that clients renew before a mass-revocation event, to soften the impact. Let's Encrypt says it provides suggested renewal windows for all issued certificates.

A client that supports ARI renews when the CA asks, instead of on a fixed timer. With lifetimes getting shorter, that is the difference between a calm renewal and an outage on a Sunday.

CAA records may need one more line later

A CAA record is a DNS record that lists which CAs may issue certificates for your domain, as defined in RFC 8659. If you use CAA and a new CA ever becomes trusted and you want to use it, you will need to add it to that list. Until then, there is nothing to add.

Quick tip: if you do not remember whether you have CAA records at all, my CAA records guide shows how to look them up and what a safe set looks like.

Expect "quantum-ready certificate" pitches

Made-up example: Priya runs a small agency with 30 client sites. In December she gets an email offering a "quantum-ready SSL upgrade" for an extra fee per site, citing the Cloudflare news. She forwards it to her developer, who points out that the CA applications are pending and the MTC format is still an Internet-Draft. Priya saves the money and adds a reminder to look again in mid 2027.

That is the right instinct. A certificate only helps you if browsers trust its issuer. Until the root programs accept a CA, a certificate from it will not be trusted by default, whatever the label says.

What you can check today

This takes about two minutes, and it is read-only, so there is nothing to back up first.

Step 1: See who issues your certificate

This command asks your site for its headers and prints the line where curl reports the certificate issuer. Replace example.com with your own domain.

curl -vI https://example.com 2>&1 | grep -i "issuer"

The -I flag fetches headers only, so it does not download your page. The -v flag makes curl verbose, and its extra lines start with *. Those lines go to standard error, which is why 2>&1 is needed so grep can see them.

You should see one line roughly like this. This output is made up for illustration; your CA name will differ.

*  issuer: C=US; O=Example Trust Ltd; CN=Example Issuing CA R1

The O= part is the organisation that issued your certificate. If you see your host's usual CA, or the CA you chose in Cloudflare, nothing has changed. If your issuer is new to you, my post on checking whether a certificate comes from a specific CA walks through reading the full chain.

Step 2: Ask whether renewals are automatic

If your host manages SSL for you, open a ticket or check their docs and ask two questions: are renewals fully automatic, and does the ACME software support renewal information (ARI). If you run your own server, check your ACME client's documentation for ARI and for the profile it requests.

Step 3: Note your CAA records

Look up your CAA records with your DNS provider or a lookup tool, and write down which CAs are listed. You are not changing anything. You just want to know the current state, so a future switch is a one-line edit and not a surprise.

What is announced versus what is final

This is where most confusion comes from, so here it is in one place.

Announced by Cloudflare, not yet final:

• Cloudflare intends to become a public CA.
• Classic certificate issuance, which waits on root program acceptance with no date given.
• Production MTC issuance, scheduled for Q1 2027, with no general availability date.
• The GlobalSign key material deal, which Cloudflare says is expected to close within two months of the 29 September announcement.

Pending with others:

• Root program applications to Chrome, Apple, Microsoft and Mozilla. Only those programs decide.
• The MTC specification, an active Internet-Draft at revision 08 (2 November 2026), not an RFC.

Already final or scheduled by others:

• RFC 9773, the ACME Renewal Information standard, published June 2025.
• RFC 8659, the CAA record standard.
• Let's Encrypt's lifetime schedule: 64 days from 10 February 2027 and 45 days from 16 February 2028, as stated at the time of writing (5 November 2026).

Notice that the parts you can act on are all in the last group. The Cloudflare parts are worth watching, not acting on.

When to look again

I would check back when one of these happens: a root program publicly accepts Cloudflare's CA, the MTC draft becomes an RFC, or Cloudflare announces general availability. Any one of those is a real signal. A sales email is not.

The one message worth forwarding

Copy this to your host, developer or team:

Hi, quick SSL check. Cloudflare announced on 29 September 2026 that it plans to become a public CA, but its root program applications are still pending and Merkle Tree Certificates are an IETF draft, so no action is needed for that. What does need attention: Let's Encrypt lifetimes drop to 64 days on 10 February 2027. Can you confirm our certificates renew automatically, whether our ACME client supports ACME Renewal Information (RFC 9773), and which CAs our CAA records allow? Thanks.

The takeaway: watch the Cloudflare CA story, but spend your time today on automatic renewals, because shorter lifetimes are the change that is already on the calendar.