Post-Quantum without bloated handshakes: Let's Encrypt's new path

Contents

Let's Encrypt has presented a concrete roadmap for quantum-secure certificates for the first time. The certification authority intends to rely on so-called Merkle Tree Certificates (MTCs) instead of simply equipping existing X.509 certificates with larger Post-Quantum signatures. A test environment is scheduled to start at the end of 2026, followed by a production-ready offering in 2027. What's new is not so much the commitment to Post-Quantum cryptography as the decision on a specific technical path.

Let's Encrypt is one of the world's most important certification authorities for automatically issued TLS certificates. The debate about quantum-secure cryptography has been ongoing for years, but has so far focused primarily on key exchange. This is driven by the concern that attackers could intercept encrypted traffic today and decrypt it later with quantum computers. Securing certificates and signatures was considered less urgent for a long time, as an attacker would need a powerful quantum computer during the ongoing communication for this. With the methods now adopted by the US standardization institute NIST and the migration plans of Google and Cloudflare, authentication is also coming to the fore.

Commitment with signaling effect

In the future, Merkle Tree Certificates are to be the preferred way to make the Web PKI quantum-secure. Let's Encrypt is already working on the necessary standards in the IETF working group PLANTS – and the issuance of MTCs will be handled via an ACME extension. The decision carries significant weight, as with hundreds of millions of active certificates, the organization significantly shapes the technical development of the Web PKI.

Let's Encrypt is not alone in this. Cloudflare and Chrome are already testing MTCs in a field trial against real internet traffic, and Chrome has declared the approach its preferred method for quantum-secure certificates on the public web.

Behind the choice lies a tangible problem with quantum-secure signatures: they require significantly more space than current methods. Let's Encrypt refers to ML-DSA-44, one of the NIST standards. Its signatures, at around 2,420 bytes, are about 38 times larger than the currently common ECDSA-P256 signatures (64 bytes). If certificates and certificate chains were switched to such methods unchanged, individual TLS handshakes would swell to over 10 kilobytes. This would slow down connections and even increase error rates in some networks.

How Merkle Tree Certificates work

Merkle Tree Certificates therefore take a different approach: Instead of signing each certificate individually, the certification authority combines many certificates into a Merkle tree. Not each individual certificate is signed, but only the root of the tree. Clients then receive a compact proof that a specific certificate belongs to this tree.

Many administrators are familiar with the principle from other areas – such as Git repositories, Certificate Transparency logs, or blockchains. Individual objects are not secured separately in each case, but are traced back to a common cryptographic anchor via a tree.

Smaller handshakes despite larger signatures

According to Let's Encrypt, this significantly reduces the authentication data in the TLS handshake. Browsers are supposed to update so-called landmarks regularly, which serve as reference points for verification. In most cases, a signature, a public key, and a Merkle proof are then sufficient. This largely avoids the additional overhead of quantum-secure signatures.

Certificate Transparency also benefits from the approach. Today, a certification authority first issues a certificate and then publishes it in separate transparency logs. With MTCs, transparency is part of the certificate model itself: Since each certificate is part of a published Merkle tree, it cannot exist outside this structure. Issuance and logging are thus brought together.

Familiar technology, long transition phase

The technology is not new territory for Let's Encrypt. The organization has been operating its own Certificate Transparency logs since 2019, which are also based on Merkle trees. It therefore already has experience in operating such structures on a large scale.

For users, nothing changes for now. Let's Encrypt will continue to issue existing certificates as usual and renew them automatically. The transition also depends on several factors: In addition to standardization by the IETF, browsers, cryptographic libraries, ACME clients, and the browser manufacturers' root programs must support the new methods.

Time is pressing for key exchange

While the transition for authentication can still be prepared calmly, Let's Encrypt is rushing with key exchange. Here, the scenario of "intercept today, decrypt later" (also known as "harvest now, decrypt later") applies, which is why every connection without quantum-secure key exchange poses a risk.

Therefore, Let's Encrypt advises server operators to activate hybrid Post-Quantum key exchange (X25519MLKEM768). Major browsers and operating systems already support this method; enabling it on the server is one of the most effective measures that can be taken this year.

Commitment to a migration path

The announcement therefore marks less the start of quantum-secure certificates than the commitment to a concrete migration path. If MTCs prevail, it will likely be one of the biggest structural changes to the Web PKI since Certificate Transparency and the ACME protocol. Let's Encrypt has published the details in a blog post on the Post-Quantum future.

(fo)