Let's Encrypt and post-quantum certificates: what changes (and what doesn't) for your server

The scary headline and the not-so-scary reality

Every few months a headline lands that has a client writing in, worried. This time it was "post-quantum certificates". On 3 June, Let's Encrypt — the non-profit certificate authority that secures more than 700 million websites — published its plan to reach the post-quantum era using something called Merkle Tree Certificates (MTCs).

Before anyone panics, here's the single most important line in the whole announcement: you don't have to do a thing today. Your certbot keeps renewing as usual, your certificates are still valid, and the timeline for all this is 2027 onwards. That said, it's worth understanding what's brewing, because it touches one of the biggest under-the-hood shifts the web has coming.

The problem: post-quantum cryptography is bulky

The underlying idea is familiar: a powerful enough quantum computer could one day break the public-key cryptography that underpins HTTPS (RSA, elliptic curves). No such machine exists yet, but quantum-resistant algorithms are already standardised by NIST, and the web needs to migrate before the problem is real, not after.

The obstacle isn't security, it's size. Post-quantum algorithms are far larger than today's:

If we took today's system and swapped the signatures for their post-quantum equivalents without changing anything else, a typical TLS handshake would balloon well past 10 KB. And here's the part many people don't see coming: Cloudflare's real-world testing shows that at that handshake size, a meaningful share of connections simply fail. It's not a theoretical problem, it's a real-network one. Swapping the algorithm by brute force would break the web.

The solution: issue in batches, not one at a time

This is where Merkle Tree Certificates come in. The idea, in plain terms:

• In today's system, each certificate carries its own signature and drags a chain of intermediate signatures along on every handshake. A lot of repeated weight on every connection.
• With MTCs, the authority issues whole batches of certificates under a single signature that covers the entire batch. Browsers stay up to date on those batch signatures (the "landmarks") on their own, out of band from the handshake.

The result? A typical MTC handshake carries one signature, one public key and one inclusion proof in the Merkle tree. And that — even using post-quantum cryptography — weighs less than the web PKI we use today. That's the elegant move: it doesn't just avoid getting heavier, it gets lighter.

There's a nice side effect: transparency is built in by design. In the current system, certificate transparency (those public logs that let you spot fraudulently issued certificates) is a layer that was bolted on afterwards. With MTCs, a certificate cannot exist outside the Merkle tree: either it's in the log or it doesn't exist. Auditability stops being an add-on and becomes the structure itself.

The timeline: this is a slow burn (and that's a good thing)

What to keep in mind so you don't stress:

• Late 2026: a staging environment that already issues MTCs, so clients and software maintainers can test.
• 2027: a production-ready environment.
• Your certificates today: still issued and renewed exactly as always. No changes.

When they arrive, post-quantum certificates will follow the same philosophy Let's Encrypt has always had: free, automated and available to anyone with an ACME client. It's not a premium product or an expensive box: it's the same model as ever.

They're not doing it alone: Google and Cloudflare proposed the same approach back in February and are already running feasibility experiments. The world's largest certificate authority lining up behind the same design as the two biggest players on the web is the signal that this is the path, not an isolated experiment.

What you need to do on your servers today

Let's be clear so nobody loses a Saturday morning over this:

1. Today, nothing. No touching certbot, no manual renewals, no config changes. Your current certificates are valid and will keep renewing themselves.
2. Keep your ACME client up to date. When the time comes, that's where the change will land: ACME clients (certbot, acme.sh, lego, your control panel's module) will need MTC support. The best preparation is the usual one: don't leave your certificate client abandoned on a three-year-old version.
3. Put this on the radar, not on the urgent to-do list. It's a deep change cooking slowly through 2026 and 2027. What matters now is knowing it exists and why, not rushing.

Our takeaway

The real message behind the scary headline is reassuring: the web is preparing for the post-quantum era sensibly, solving a size problem along the way that would have broken connections if done by brute force. And it does so without asking anything of the everyday administrator today.

Our stance here is the usual one: we note it, we follow it, and we'll recommend it once it leaves staging and proves reliable in production. In the meantime, the best favour you can do yourself is to have certificate renewal automated and your client current — which is exactly what you should already have for other reasons. If you'd like us to review how certificate management is set up on your servers, drop us a line.

References

• A Post-Quantum Future for Let's Encrypt — Let's Encrypt
• Let's Encrypt works toward post-quantum certificates at web scale — Help Net Security
• Post-Quantum without bloated handshakes: Let's Encrypt's new path — heise online