📜 PKI Migration
PQC PKI & Certificate Migration
The certificate infrastructure is the hardest part of PQC migration. X.509, CAs, hybrid certificates, ACME, browser trust — here is the complete reference.
⚠️ Why PKI is hardest: The entire CA trust hierarchy must migrate simultaneously. A PQC leaf certificate is useless if the intermediate and root CAs still use RSA. Browser trust store changes are slow. ACME protocol needs updates. Certificate lifetimes affect migration timelines. Plan 3–5 years for full PKI migration.
The PKI Migration Challenge
Public Key Infrastructure (PKI) underpins HTTPS, code signing, email signing, VPN, and authentication. Every X.509 certificate today uses RSA or ECDSA — both completely broken by Shor's algorithm. Migrating PKI requires coordinated changes across every layer of the trust hierarchy.
The trust chain problem
Root CA
Trust anchor — embedded in browser/OS trust stores. Takes years to get new roots into trust stores. Root CAs must migrate to PQC or create new PQC root CAs.
Critical bottleneck
Intermediate CA
Signed by Root CA. Issues leaf certificates. Must be re-signed by PQC Root CA to establish quantum-safe chain.
Required before leaf certs work
Leaf Certificate
The certificate on your website or service. Migration is easiest here — short lifetimes (90 days for Let's Encrypt) mean rapid rollover.
Fastest to change
Client/Browser
Must understand and validate PQC signature algorithms in certificates. Browser updates needed to support ML-DSA certificate verification.
Vendor-dependent rollout
X.509 certificate changes for PQC
| Certificate Field | Classical Value | PQC Value | Notes |
|---|---|---|---|
| Subject Public Key Algorithm | rsaEncryption (1.2.840.113549.1.1.1) or id-ecPublicKey | id-ML-DSA-65 (2.16.840.1.101.3.4.3.18) or id-ML-DSA-87 | OID assignments for FIPS 204 ML-DSA now defined in IETF RFC 9629 |
| Signature Algorithm | sha256WithRSAEncryption or ecdsa-with-SHA256 | id-ML-DSA-65 or id-ML-DSA-87 | Same algorithm signs the cert as the key type of the issuing CA |
| Public Key Size | RSA-2048: 256 bytes. P-256: 64 bytes | ML-DSA-65 public key: 1,952 bytes | ~7× larger than ECDSA. Impacts TLS handshake size — monitor latency |
| Signature Size | RSA-2048: 256 bytes. ECDSA P-256: ~72 bytes | ML-DSA-65 signature: 3,293 bytes | ~45× larger than ECDSA. Certificate chain size increases significantly |
| Key Usage | digitalSignature, keyEncipherment (RSA) | digitalSignature only — ML-KEM handles key exchange separately | No more combined sign+encrypt in one cert — separation is cleaner |
Hybrid Certificates — The Transition Mechanism
A hybrid certificate contains both a classical (RSA/ECDSA) signature and a PQC (ML-DSA) signature. This allows the same certificate to be validated by both classical clients (using the RSA/ECDSA part) and PQC-capable clients (using the ML-DSA part). This is the primary transition mechanism for the 2025–2028 migration period.
Hybrid certificate approaches
| Approach | Standard | How It Works | Status | Trade-off |
|---|---|---|---|---|
| Composite certificates | draft-ietf-lamps-pq-composite-sigs | Single X.509 cert with composite public key and composite signature — both classical and PQC algorithms required to validate. | IETF LAMPS WG — active draft, pre-RFC | Larger certificate. Both algorithms must be verified — increases computation. |
| Dual-certificate (cert pair) | No IETF standard — implementation choice | Issue two separate certificates for the same entity — one RSA/ECDSA, one ML-DSA. Server selects based on client capability. | Implementable today. Used by some CAs in trials. | Operational complexity — two certs to manage. No standard negotiation mechanism. |
| X.509 Alt-Sig extension | draft-ietf-lamps-cert-binding-for-multi-auth | Classical cert with additional PQC signature in an extension field. Backward compatible — old clients ignore the extension. | Active IETF draft | Less overhead than full composite. Cleaner backward compatibility. |
| Catalyst / chameleon certs | Research / Cloudflare experiments | Certificate appears as standard RSA cert to classical verifiers but contains hidden PQC signature verified by PQC-aware clients. | Research stage — not standard | Complex to implement. Clever but creates hidden dependencies. |
Generate a hybrid certificate today (OpenSSL + OQS provider)
# Using OQS-enabled OpenSSL with ML-DSA
# Generate ML-DSA-65 private key
openssl genpkey -algorithm ML-DSA-65 -out mldsa_key.pem
# Generate Certificate Signing Request
openssl req -new -key mldsa_key.pem \
-out mldsa_csr.pem \
-subj "/CN=example.com/O=My Org/C=US"
# Self-sign for testing (or send CSR to a PQC-capable CA)
openssl x509 -req -in mldsa_csr.pem \
-signkey mldsa_key.pem \
-out mldsa_cert.pem \
-days 365
# Inspect the certificate
openssl x509 -in mldsa_cert.pem -text -noout | grep -A2 "Public Key Algorithm"
# Expected: Public Key Algorithm: ML-DSA-65
CA & Browser Support Status (2024–2025)
| Organisation | PQC Certificate Support | Status | Notes |
|---|---|---|---|
| DigiCert | ML-DSA hybrid certificates | Pilot available (2024) | DigiCert has issued PQC test certificates. Working with enterprise customers on migration planning. |
| Entrust | PQC certificate trial programme | Pilot available | Entrust CryptoCenter supports PQC certificate issuance for enterprise customers. |
| Sectigo | PQC certificate research | In development | Working on hybrid cert support — no public pilot at time of writing. |
| Let's Encrypt / ISRG | ACME PQC extension in development | Not yet — monitoring IETF ACME WG | Let's Encrypt dependent on ACME protocol PQC extension (draft-ietf-acme-pqc). Expected ~2025–2026. |
| Microsoft CA (ADCS) | PQC support in development | Not yet — expected in Windows Server update | Microsoft has committed to PQC support in Active Directory Certificate Services. |
| AWS Private CA | PQC roadmap committed | Not yet — vendor roadmap | AWS Private CA PQC support expected when FIPS 140-3 validated modules available. |
| Google Trust Services | PQC research | Research stage | Google running internal PQC cert experiments — not publicly available. |
| Open Quantum Safe (OQS) | Full PQC test CA | Available — testing only | OQS provides a test CA hierarchy for development and testing. Not trusted by browsers. |
| Chrome | ML-DSA certificate validation | In development (V8/BoringSSL) | Chrome 2024+ has partial ML-DSA verification capability. Full cert chain support coming. |
| Firefox | ML-DSA certificate validation | In development | NSS library (Firefox crypto) being updated for ML-DSA cert verification. |
| Safari / Apple | PQC certificate support | In development | Apple has not announced timeline but iOS/macOS cert validation will follow. |
PKI Migration — Step by Step
1
Inventory your certificate estate
Enumerate all certificates across your infrastructure: TLS certs, code signing certs, client auth certs, internal CA hierarchy, email signing certs. Use tools like Cert Manager, HashiCorp Vault, or DigiCert CertCentral. Know what you have before you can migrate it.
2
Set certificate automation as a prerequisite
If you are not already using automated certificate renewal (ACME via certbot, cert-manager for Kubernetes, AWS Certificate Manager), set this up first. Manual certificate management at scale during a migration is not feasible. Automation is the prerequisite, not the nice-to-have.
3
Establish a PQC test CA environment
Deploy an OQS-enabled OpenSSL CA for internal testing. Issue PQC test certificates to internal services. Validate that your application stack can handle larger certificate sizes (ML-DSA certs are ~15KB vs ~1–2KB for ECDSA). Test TLS handshake performance with PQC cert chains.
4
Monitor IETF LAMPS WG progress
The X.509 PQC certificate format, hybrid certificate standards, and ACME PQC extension are all being defined in the IETF LAMPS and ACME working groups. Track draft-ietf-lamps-pq-composite-sigs and draft-ietf-acme-pqc. These become the standards you will deploy when CAs and browsers support them.
5
Engage your CA vendor
Ask your current CA (DigiCert, Entrust, Sectigo, Let's Encrypt) for their PQC roadmap. If you use an enterprise CA (ADCS, EJBCA, Vault PKI), check their PQC timeline. This is a vendor dependency — the CA must support PQC before you can issue PQC certs publicly.
6
Plan root CA transition
The hardest part: new PQC root CAs must be embedded in browser/OS trust stores. This takes 3–5 years from CA application to universal trust. Microsoft, Apple, Mozilla, and Google run trust store programs — CAs must apply for inclusion. Plan for a long parallel operation of classical and PQC root CAs.
7
Issue hybrid certificates when CA support available
When your CA supports hybrid certs (composite or dual-cert), begin issuing hybrid certs for internet-facing services. These work for all current clients while providing PQC protection for PQC-capable clients.
8
Migrate internal PKI fully to PQC
Internal systems (internal APIs, VPN, mTLS service mesh) do not need public CA trust — you control the trust store. Migrate internal CA to ML-DSA first. This is your fastest full-PQC win.
9
Complete public cert migration when browsers support PQC
Once major browsers support ML-DSA certificate validation and public CAs offer PQC certs: retire hybrid certs in favour of pure PQC certificates. This is the final step — estimate 2027–2030 for broad readiness.
ACME Protocol & Let's Encrypt — PQC Path
The ACME protocol (RFC 8555) is used by Let's Encrypt and other CAs for automated certificate issuance. ACME itself uses RSA/ECDSA for account key signatures and certificate request signing. Full PQC migration of Let's Encrypt requires updates to both the ACME protocol and Let's Encrypt's backend.
Current state
IETF ACME WG
draft-ietf-acme-pqc is in progress — defines how ML-DSA account keys and CSRs work with ACME. Not yet RFC.
Active — tracking
Let's Encrypt backend
Let's Encrypt uses ISRG root CAs. New PQC root CAs would need to be created and trusted by browsers before PQC cert issuance via Let's Encrypt is possible.
Not yet — 2025–2026 target
certbot client
certbot would need an update to support ML-DSA key generation and ACME PQC draft.
Pending ACME RFC
cert-manager (Kubernetes)
cert-manager is ACME-based — will inherit ACME PQC support when available.
Pending upstream ACME
HashiCorp Vault PKI
Vault can act as internal CA. PQC certificate issuance in Vault planned — check release notes for your version.
In roadmap
What you can do today
→
Use Let's Encrypt for leaf certs as normal — 90-day rotation means when PQC becomes available, the transition is fast.
→
Set up internal PQC CA using OQS-OpenSSL for internal services now — does not require Let's Encrypt.
→
Track draft-ietf-acme-pqc and Let's Encrypt blog for PQC announcement.
→
Ensure cert-manager or certbot is kept up to date — PQC support will arrive in a standard update.