Your bot trusts certificates blindly.
That is usually fine. You call an API, the TLS handshake succeeds, your code moves on. Nobody writing a Discord bot or a scraping pipeline thinks about who signed the certificate on the other end, and that is sort of the point of the system working well.
On September 29, 2026, Cloudflare announced its intent to become a public Certificate Authority, an open service that will issue the digital certificates websites use to encrypt traffic and prove identity. The part that caught my attention as someone who ships automation for a living is the roadmap. The new CA will issue classical certificates first. Post-quantum Merkle Tree Certificates come after, with production MTC issuance scheduled for the first quarter of 2027, following the browser root program application and acceptance process.
Two different things are happening in that sentence, and they land on bot builders in two different ways.
A new root means a new trust store problem
Browsers get root certificate updates handled for them. Your bots mostly do not.
Think about where TLS trust actually lives in a typical automation stack. Python pulls its roots from certifi, a package pinned in a requirements file that may not have been touched in a year. Node bundles its own root list into the runtime, so your trust store version is effectively whatever Node version your Dockerfile froze. Go reads the system pool. Alpine containers depend on ca-certificates, which is only as current as your last image rebuild. Some teams go further and pin specific roots or leaf certificates for API calls they consider sensitive.
Every one of those layers is a place where a newly accepted CA root is absent until somebody updates something. When a CA enters browser root programs, the sites using it work fine in Chrome and Safari while your six-month-old container image throws verification errors against the same endpoints. I have debugged that class of failure more than once, and it always looks like a network problem for the first twenty minutes.
What I would actually check
- Find every HTTP client in your stack and write down where it gets its root list. Not where you assume it does. Where it actually does.
- Unpin or regularly bump your trust bundle dependency. A stale
certifipin is a slow-moving outage. - Rebuild base images on a schedule instead of only when code changes. Trust stores age even when your code does not.
- Audit certificate pinning. Pinning to a specific issuer is a reasonable control, but it becomes a liability the moment the service you depend on changes CAs.
- Make TLS verification failures loud and distinguishable in your logs. “Connection error” tells you nothing at 2 a.m.
None of that is new advice. The Q1 2027 date just gives you a reason to do it before it becomes urgent.
Merkle Tree Certificates and the size question
The post-quantum half is the more interesting engineering story. Post-quantum signatures are large compared to the classical ones we use today, and TLS handshakes are sensitive to size in a way most application developers never notice. Merkle Tree Certificates are a design response to that problem, which is why Cloudflare is treating them as a separate track with a later ship date rather than flipping a switch on existing issuance.
For bot builders, the practical implication is that handshake behavior may shift under you. If you are running thousands of short-lived connections, say a crawler that opens a fresh TLS session per request, handshake cost is already a real line item in your latency budget. Changes to certificate format and chain structure are exactly the kind of thing that shows up as a mysterious p99 regression months later.
This is a good argument for things you should be doing anyway. Reuse connections. Keep session resumption on. Measure handshake time separately from total request time so you can tell the difference between a slow server and an expensive negotiation.
Why this matters more for automation than for people
A human visiting a broken site reloads, shrugs, or updates their browser. A bot retries the same failing call four hundred times and fills your error budget. Automation has no judgment about trust, which means the correctness of your certificate verification is entirely a function of decisions you made at build time, possibly a long time ago.
The migration to post-quantum TLS is going to be a multi-year grind of root programs, client updates, and container rebuilds. Cloudflare is one of the first authorities moving toward issuing certificates built on cryptography believed to resist quantum attack, and the staged approach, classical first and MTCs in early 2027, is honest about how long the plumbing takes.
You have until then to find out where your bots keep their trust. Start with the oldest Dockerfile.
🕒 Published: