Why Post-Quantum Certificates Break the TLS Handshake Budget
Post-quantum certificates are not hard because cryptographers forgot how certificates work.
They are hard because the WebPKI was built in a world where signatures were small enough that we kept adding more of them.
That worked with ECDSA and RSA. It gets uncomfortable when the certificate chain starts carrying post-quantum public keys and signatures.
Where today's handshake spends certificate bytes
Handshake cost pressure points
Small signatures made extra proof cheap.
Post-quantum signatures are much larger.
Traditional WebPKI repeats signatures and keys in the handshake.
A compact proof can replace much of the on-wire signature cost.
The current WebPKI is patched together for good reasons
A normal public TLS handshake has the server proving possession of its private key, a leaf certificate, usually an intermediate certificate, and Certificate Transparency evidence. Those layers exist because the WebPKI had to scale trust across billions of endpoints and hundreds of CAs.
The problem is not that those layers are wrong. The problem is that each layer was cheap when public keys and signatures were small.
Post-quantum signatures change the economics
Cloudflare's MTC write-up points at the practical issue: ML-DSA-44 signatures are measured in thousands of bytes, not dozens. Let's Encrypt makes the same point in its June 2026 post: a typical WebPKI handshake today carries multiple signatures and public keys, and replacing all of that directly with post-quantum material is a rough default.
That is why Chrome has said it is not planning an immediate drop-in move to traditional X.509 certificates containing post-quantum cryptography in the Chrome Root Store. The performance budget matters.
MTC moves proof out of the hot path
Merkle Tree Certificates change the shape of the proof. A CA commits issued certificates into a public Merkle tree. The client can receive tree information out of band. During the handshake, the server can send a compact inclusion proof instead of making the client process the same heavy signature pattern every time.
There are fallbacks and details. Clients need to be up to date. Servers may need both landmark-relative and standalone forms. But the direction is straightforward: keep TLS fast while giving the WebPKI a path to post-quantum authentication.
What this means for operators
The operator job does not disappear. HAProxy still needs the right certificate material. IIS still needs the binding. Nginx still needs the file path and reload. ACME clients still need to understand what they are downloading. Monitoring still has to prove what the endpoint served.
CertLocker is useful in that layer: inventory, ACME state, delivery tokens, endpoint probes, and audit. When certificate formats evolve, the team with clean operational state will have a much easier migration.
Handshake-budget readiness checklist
- ✓ Know which services terminate TLS and which clients depend on them.
- ✓ Track certificate chains, not only leaf expiry dates.
- ✓ Identify ACME clients and libraries that may need MTC support later.
- ✓ Probe handshakes after certificate delivery and reload.
- ✓ Keep old-device and middlebox risk visible before changing TLS behavior.
- ✓ Watch Chrome, Let's Encrypt, Cloudflare, and IETF PLANTS implementation notes.
Related reading and workflows
Part 1: Where WebPKI is going
Why MTC is becoming the likely post-quantum certificate direction.
Google on quantum-safe HTTPS
Chrome explains why it is developing MTC-based HTTPS certificates.
Let's Encrypt post-quantum WebPKI plans
Let's Encrypt explains the practical certificate-size problem.
Certificate lifecycle management
Inventory, renewal, delivery, ownership, and audit for TLS certificates.
Certificate delivery tokens
Scoped certificate access for HAProxy, IIS, Nginx, scripts, and automation.
Endpoint probes
Check what production endpoints actually serve after renewal.
Help with onboarding
Bring your existing inventory to a hosted walkthrough with the CertLocker engineers.
CertLocker for DevOps teams
The broader trust-control workflow for platform and infrastructure teams.
Compare CertLocker with scripts
Where spreadsheets, cron jobs, and shared files stop being enough.
Try the workflow against real infrastructure
Use the hosted evaluation at trust.certlocker.io for a walkthrough, or run a one-month onsite evaluation against your own certificates, hosts, secrets, and access paths.