← Back to Blog Tutorials

ACME and PQC: Let's Encrypt Roadmap

11 min read

The Automatic Certificate Management Environment, better known as ACME, is the protocol that quietly makes most of the modern web work. Every time you visit a site that starts with HTTPS and uses a free certificate from Let's Encrypt, you are seeing ACME do its job. The protocol fetches a certificate, proves your control over a domain, installs the cert, and then renews it again and again, all without a human being involved.

ACME has worked beautifully for traditional cryptography. The next question is whether it can carry the same load when post-quantum signatures replace RSA and ECDSA. The answer is yes, but the path forward is being built right now, and operators who plan ahead will avoid painful surprises later.

How ACME Works Today

ACME is defined in RFC 8555. The protocol is a sequence of HTTP requests between a client (your server, or a tool like Certbot) and a Certificate Authority (CA). The CA gives you a challenge that proves you control a domain. You complete the challenge, the CA verifies it, and then a certificate is issued. The whole exchange is signed using JSON Web Signatures (JWS), which today rely on RSA or ECDSA.

The brilliance of ACME is its simplicity. A small server can fetch a fresh 90-day certificate without any manual paperwork. Let's Encrypt issues hundreds of millions of these certificates every year. The protocol is so widely adopted that the IETF made it a formal standard, and most large CAs now support it in addition to traditional issuance.

Why PQC Matters for ACME

Two cryptographic operations live at the heart of ACME. First, the client signs requests so the CA knows the same account is talking to it across renewals. Second, the issued certificate itself contains a signature from the CA, and that signature is what browsers check when a user connects to the site.

Both signatures are vulnerable to a future cryptographically relevant quantum computer. RSA-2048 and ECDSA-P256 can be broken by Shor's algorithm running on enough qubits. Long-lived root and intermediate certificates are particularly exposed because they sit in trust stores for years, sometimes decades. If an attacker harvests issuance data today and a quantum computer arrives later, they could in theory forge certificates and impersonate any site that was issued during the harvest window.

For background on why classical RSA is at risk, see why-rsa-2048-will-break.

The Let's Encrypt Stack: Boulder and Pebble

Let's Encrypt runs two open-source projects that together let any developer test or deploy an ACME flow.

Boulder is the production CA software. Written in Go, it handles the millions of issuance requests Let's Encrypt processes every day. Boulder is an extremely battle-tested codebase and any change to its cryptographic surface has to be considered carefully because mistakes affect a huge fraction of the public internet.

Pebble is a small, single-binary ACME server. The Let's Encrypt team built Pebble specifically as a developer tool. It does not do real validation, it does not need a database, and it issues throwaway certificates that are useful for testing client behavior. Pebble is also the natural place to prototype new features like post-quantum signatures, because nothing about its certificates ends up in a real trust chain.

Pebble's role in PQC experimentation is important. When new signature algorithms ship, ACME client developers need a server they can point at to verify their changes. Pebble plays that role.

ML-DSA Cert Issuance Roadmap

The first NIST-standardized post-quantum signature is ML-DSA, formerly known as Dilithium. The standard is described in FIPS 204, which the National Institute of Standards and Technology published in August 2024. ML-DSA comes in three parameter sets: ML-DSA-44, ML-DSA-65, and ML-DSA-87, with the number roughly tracking security strength.

For ACME, the relevant question is when CAs will accept ML-DSA in JWS for client requests, and when they will issue certificates whose signature is ML-DSA. The ACME spec itself does not need a major revision. The JWS layer accepts new algorithm identifiers, and ML-DSA can be added by registering a new algorithm name. The harder work is at the CA. Boulder needs to know how to verify ML-DSA on incoming requests, generate ML-DSA keypairs for new intermediates, and produce certificates whose signature field carries ML-DSA.

Today most CAs are running pilots in test environments. The final blocker is that browsers and clients also need to accept ML-DSA in TLS, so the moment a CA can issue an ML-DSA certificate is the same moment that browsers must verify it. This is why hybrid certificates, which combine a classical signature with a post-quantum one, are the most likely first deployment.

For an introduction to ML-DSA itself, see mldsa-vs-slhdsa.

ACME Extension Drafts

Several IETF drafts extend ACME to handle post-quantum specifics. They cover the algorithm registration that lets a client request a PQC-signed certificate, the way a CA advertises which algorithms it supports through its directory endpoint, and the formats for hybrid certificates that contain both classical and post-quantum public keys.

A second class of drafts focuses on the operational reality of certificate transparency. Today every public certificate is logged to a Certificate Transparency log, and those log entries are themselves signed. If logs continue to use ECDSA, an attacker with a quantum computer could potentially forge log entries about historical issuance. The drafts address this by allowing logs to use post-quantum signatures or hybrid signatures.

The IETF process for these drafts is healthy but slow. ACME has working group members from major CAs, browser vendors, and tooling providers, and they all have opinions. That is a feature, not a bug. The protocol that issues most of the world's certificates needs to be conservative.

Hybrid Certificates and Why They Matter

A hybrid certificate carries two signatures. One is classical, signed with RSA or ECDSA. The other is post-quantum, signed with ML-DSA or another approved algorithm. The certificate is valid only if both signatures verify. This pattern matches the broader hybrid encryption strategy that NIST and CISA recommend for the transition period.

For more on hybrid encryption and signatures, see hybrid-encryption.

The advantage of hybrid is backward compatibility. A browser that does not understand ML-DSA still validates the classical signature, so the site continues to work. A modern browser that does understand ML-DSA gets the additional protection. Hybrid certificates are larger than classical certificates, which has implications for TLS handshake size and CDN caching, but the size penalty is acceptable for most use cases.

The downside is complexity. Both signatures must be created at issuance, both must be verified, both keys must be managed, and both must be rotated. This is the operational price of crypto agility.

For a deeper guide to staying agile during the migration, see crypto-agility-explained.

Client Side: Certbot, acme.sh, and Others

The most popular ACME client by far is Certbot, maintained by the Electronic Frontier Foundation. Certbot is written in Python and uses the cryptography library for its key operations. Adding ML-DSA to Certbot means adding it to the cryptography library first, which in turn means waiting for OpenSSL or another underlying provider to support the algorithm.

acme.sh is a popular shell-based client that uses OpenSSL directly. Its PQC story is therefore tied to OpenSSL's PQC story. OpenSSL 3.5 ships with ML-KEM and ML-DSA support, and acme.sh will inherit that capability as soon as the operator updates the OpenSSL binary.

Lego, a Go-based client used by Traefik and other reverse proxies, depends on Go's crypto library. Go 1.22 added support for several post-quantum algorithms, and the Go crypto team has been steadily adding more.

The pattern is clear. Clients are not the bottleneck. The bottleneck is the underlying cryptographic library and the CA's willingness to issue PQC certificates.

Operational Considerations for Site Operators

If you operate a site that uses Let's Encrypt today, what should you do? The honest answer is mostly nothing for the moment. Let's Encrypt has not yet issued post-quantum certificates in production. When they do, your ACME client will pick up the new algorithm automatically as long as you keep it updated.

The one piece of preparation worth doing now is testing your TLS termination layer for handshake size. ML-DSA signatures and hybrid certificates are larger than ECDSA, and some load balancers, web application firewalls, or older middleboxes choke on TLS records above a certain size. Testing with experimental hybrid certificates against your stack today reveals these limits before they become production incidents.

A second piece of preparation is monitoring. If your stack alerts on certificate expiration or rotation failures, make sure those alerts also fire if a renewal switches algorithm. A surprise switch to a new algorithm without operational awareness is exactly the situation that causes outages.

For a step-by-step migration approach, see hybrid-migration-strategy-step-by-step.

What CAs Need to Solve

For a CA to ship PQC certificates broadly, it needs more than a working code path. It needs trust store inclusion. Browsers, operating systems, and embedded devices all carry root certificates that anchor trust. A new PQC root, even a hybrid one, has to be added to those trust stores, and that process can take years for embedded systems. CAs typically issue from intermediates that chain to existing roots, which softens the problem because new intermediates can be deployed faster than new roots, but the long-term durability of the system depends on root rotation.

CAs also need PQC keys for their own private use. The hardware security modules (HSMs) that hold root keys need to support the new algorithms. NIST has published a guide for FIPS-validated PQC implementations, and HSM vendors are working through certification. For more on FIPS, see nist-fips-guide.

The Harvest-Now Problem

A common question is whether ACME certificates are subject to the harvest-now-decrypt-later threat. The answer is nuanced. The signature on a certificate does not encrypt anything, so a future quantum computer cannot decrypt past TLS sessions just because it can break the signature. But it can forge certificates from any historical CA whose key it cracks, which means an attacker can impersonate sites in the future based on data captured today.

This is why migrating to PQC root keys is a higher priority than migrating to PQC leaf certificates for some operators. The leaf cert lifetime is 90 days for Let's Encrypt. The root cert lifetime is decades. For a fuller treatment, see harvest-now-decrypt-later.

Frequently Asked Questions

Will my Let's Encrypt cert stop working when PQC ships? No. Hybrid certificates are designed for backward compatibility. Classical-only certificates will continue to be issued and validated for years. The transition will be gradual and overlapping.

Can I get a PQC certificate from Let's Encrypt today? Not in production. You can experiment with Pebble, the developer ACME server, which can be configured to issue test PQC certificates. These are not trusted by browsers.

How big are PQC certificates? ML-DSA-65 signatures are roughly 3.3 kilobytes, compared to about 64 bytes for ECDSA-P256. The certificate itself can grow to several kilobytes for hybrid variants. This is large but not breaking for HTTPS.

Do I need to do anything to my web server right now? Keep your TLS library current. OpenSSL 3.5, BoringSSL, and Rustls are all on track to ship PQC support, and updating to current versions is the simplest preparation.

What happens to certificate transparency logs? The CT logs themselves will need PQC signatures to remain trustworthy long term. This is a parallel migration that the log operators are working on, separate from the issuance side.

Sources

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

Try QNSQY