Abstract
On June 3, Let’s Encrypt announced that the post-quantum web is going to run on something called Merkle Tree Certificates. The internet did what it does and turned this into a doomsday Q-Day countdown. The quantum computers are coming, your certificates are about to break, panic!
Unlike every other security vendor, I’m not worried about quantum computers.
But the announcement is still worth your attention. Just not for the reason you’ve been told.
When will quantum computers break encryption?
Here’s a way to think about it that has nothing to do with qubits.
When the United States decided to build the atomic bomb, it found nearly every physicist on Earth who understood the theory and moved them to the desert. Fermi, Bohr, Oppenheimer, the whole field. And then they went quiet. The papers stopped. The conference talks stopped. People who had been publishing for twenty years simply vanished from the literature. That silence was the tell. When a small group of people who can do an impossible thing all disappear at once, something is being built.
That is not happening with quantum computing.
The people who could build a cryptographically relevant quantum computer are a small field, and you can name a lot of them. They work at Google and IBM and a handful of universities. They publish. They present. They argue with each other at conferences in public. Nobody has gone dark. So either we are not close, or there is a secret volcano lair somewhere staffed by brilliant scientists no one has ever heard of, building a machine in total silence.
Expert surveys put the central guess for when quantum computing becomes real somewhere around 2033 to 2037. In an actual lab, no one is close. Even Let’s Encrypt says it plainly: the threat to authentication “hasn’t materialized yet.”
So why is the largest certificate authority rebuilding its entire stack around a threat that hasn’t shown up? That’s what is interesting.
The problem isn’t math, it’s performance
A signature is how a certificate proves it’s real. The certificate authority signs your certificate with its private key, which allows every browser to validate that your certificate can be trusted. The whole thing rests on math that’s easy to do one direction and effectively impossible to reverse. That asymmetry is the security. A quantum computer, if one ever existed at scale, is exactly the machine that could reverse that math and forge signatures at will.
To prevent that, we need a new “post-quantum” way of doing signatures. We have a way to do it, they are just ENORMOUS.
A certificate signature today is 64 bytes. ML-DSA-44 is one of the smaller standardized post-quantum signature schemes, and its signature is about 2,420 bytes. That’s 38x larger. A typical TLS handshake carries five signatures and two public keys, and swapping them for post-quantum equivalents would push a single handshake past 10 kilobytes.
| Algorithm | Signature | Public key |
|---|---|---|
| ECDSA P-256 | 64 bytes | 64 bytes |
| RSA-2048 | 256 bytes | 256 bytes |
| ML-DSA-44 | 2,420 bytes | 1,312 bytes |
10 kb doesn’t seem like a lot, until you realize how many concurrent connections are required to browse the modern web. There are hundreds of requests across dozens of hosts for even the smallest webpages today. Cloudflare measured this on real traffic. Once a certificate chain adds more than 10KB, the rate of client and network failures climbs sharply, connections that used to work just stop. And even when it stays under that line, the handshake itself runs about 15% slower. Every connection pays the tax. All of it in exchange for security against a threat that is, at best, a decade out.
This is the part the industry already knows in its bones: the web will not accept being slower for theoretical safety. It never has.
We ran this experiment before, with revocation. OCSP was supposed to let browsers check whether a certificate had been revoked, and it worked, technically. It also added a network round trip and a privacy leak to the start of every connection. Nobody wanted to pay that cost. Browsers soft-failed the check rather than slow things down, which meant it stopped providing the security it promised, and the industry eventually walked away. Let’s Encrypt stopped including OCSP in its certificates in 2025. Performance won. The theoretically-correct-but-slow thing lost.
Anyone who works in web performance, like we do, can tell you how this ends. A few hundred milliseconds of added latency is not a rounding error, it’s a measurable hit to conversion and engagement that businesses actively defend against. A multi-kilobyte handshake on every connection is exactly the kind of cost the web spits back out. So a naive post-quantum swap was never going to happen. Something had to give on size.
What a Merkle Tree Certificate actually does
This is what Merkle Tree Certificates are for. Not quantum resistance for its own sake, but quantum resistance that doesn’t make the web slower.
The trick is batching certificate signatures. Instead of signing each certificate individually, the certificate authority issues certificates in batches and signs the entire batch with one signature. Browsers stay current on those batch signatures, called landmarks, out of band, separate from the handshake. When a connection happens, the certificate you present is reduced to one signature, one public key, and one small proof that your certificate is included in the batch. The result is a handshake that’s actually smaller than today’s, even though it uses post-quantum algorithms.
There’s a second thing MTCs get almost for free. Because every certificate has to live inside a published Merkle tree to exist at all, Certificate Transparency stops being a separate system bolted on after issuance. Today a certificate gets issued, then logged, with extra signatures riding along in the handshake to prove it was logged. With MTCs, a certificate cannot exist outside the tree. Transparency is the issuance.
This isn’t a moonshot for Let’s Encrypt, either. They’ve run Certificate Transparency logs since 2019, and those logs are append-only Merkle trees, the exact data structure MTCs are built on. They’re targeting a staging environment in late 2026 and production in 2027.
The part no one is saying out loud
Merkle Tree Certificates make even shorter-lived certificates possible, and maybe inevitable.
Think about what made short lifetimes painful before. Every certificate was an individual signing event, individually logged, individually tracked. Batch issuance and built-in transparency strip out that friction. Once the cost of issuing and logging a certificate collapses, the natural lifetime collapses with it. MTCs don’t just tolerate shorter certificates, they remove every reason not to go shorter.
And this lands on top of a trend that’s already in motion for completely unrelated reasons. Public certificate lifetimes are dropping to 47 days by 2029 because of browser policy. Now you have a second force, post-quantum architecture, pushing in the same direction. Certificates that turn over faster and faster, in more formats per server, with no flag day and no announcement that the work just changed under you.
No quantum apocalypse. Just more renewals, and more kinds of certificate living on each server, than the scripts were built for. This is the same problem we keep coming back to: issuing a certificate is the easy part. Keeping them deployed correctly is the part that breaks.
The one thing worth doing today
If you want something concrete to take from all this, here it is, and it’s small.
The one real risk you can act on today has a name: harvest now, decrypt later. The threat is to encryption, not authentication. Someone (probably the NSA) can record your encrypted traffic today, sit on it, and decrypt it years from now if a quantum computer ever arrives. That’s the one piece of the threat that works retroactively, which is exactly what makes it worth acting on now while everything else waits. Turn on hybrid post-quantum key exchange (X25519MLKEM768) at your servers. Major browsers and operating systems already support it. It’s the single highest-leverage thing you can do this year.
Everything else, the new certificates, the new algorithms, the MTC issuance flow, is a 2027-and-later problem you can’t act on yet because it doesn’t exist yet.
What this is really about
Maybe quantum computers break RSA in 2035. Maybe they never do. Either way, the certificates you manage are going to churn again. Shorter lifetimes are coming because of browser policy. Even shorter ones are coming because of post-quantum architecture. New certificate formats are coming because the old ones don’t fit.
The teams that will ride all of this without noticing are the ones that automated the lifecycle instead of scripting issuance. The ones still running cron jobs and calendar reminders will find out about each change the hard way.
That’s the interesting part. It has nothing to do with quantum computing.
CertKit handles the certificate lifecycle, so the next churn is a config change instead of a project.
Comments