# Certificate Lifecycle Management and PQC **Source**: https://quantumsequrity.com/blog/cert-lifecycle-pqc **Category**: Operations --- [← Back to Blog](../../blog.html) Operations # Certificate Lifecycle Management and PQC 11 min read X.509 certificates have been the connective tissue of the public web for thirty years. They authenticate web servers, code signers, S/MIME senders, VPN endpoints, IoT devices, and countless internal services. The certificate lifecycle (issuance, deployment, renewal, revocation, retirement) is one of the most operational, least glamorous parts of cryptographic infrastructure. Post-quantum cryptography changes the certificate lifecycle in two ways. The signature algorithms inside certificates are migrating from RSA and ECDSA to ML-DSA, hybrid, or both. And the validity periods are getting shorter, with the CA/Browser Forum reducing maximum validity from 398 days (the current 90-day TLS norm) toward 47 days by 2027 and possibly 10 days thereafter. This article walks through how the certificate lifecycle is changing, what ACME (RFC 8555) automation looks like with PQ certs, and what organizations should do today to prepare. ## The Pre-PQC Certificate Lifecycle Before walking into changes, let us recap the classical lifecycle: 1. **Generate keypair** on the subject (server, person, device). Typically RSA-2048 or ECC-P256. 2. **Generate Certificate Signing Request (CSR)**. The CSR contains the public key and identity information, signed by the corresponding private key. 3. **Submit to CA**. The CA validates the identity claim (domain validation, organization validation, extended validation). 4. **CA signs the certificate**. Using the CA's private key, typically RSA-2048 or larger, or ECC. 5. **Deploy the certificate**. Configure the server, sign the code, etc. 6. **Periodic renewal**. Before the validity period ends, repeat the above. 7. **Revocation if needed**. If the private key is compromised or the cert is no longer needed, the CA publishes a revocation entry (CRL or OCSP). ACME (RFC 8555), introduced by Let's Encrypt and now widely adopted, automates steps 2-5. ACME made certificates effectively free and pushed validity periods down from years to 90 days as the new norm. ## PQC Certificates: What Changes A PQ-signed certificate is structurally similar to a classical certificate but has two PQ-relevant fields: 1. **Subject Public Key**: The certificate holder's public key. May be ML-KEM (for KEM use), ML-DSA (for signing), or a hybrid like ML-DSA-65 + Ed25519. 2. **Signature**: The CA's signature over the certificate body. May be ML-DSA, hybrid, or classical (during transition, intermediate CAs may sign with classical while leaf certificates have PQ public keys). The PQ certificate is larger. ML-DSA-65 public keys are about 1952 bytes, signatures about 3309 bytes. Compared to ECC-P256 public keys (32 bytes) and signatures (64 bytes), the size growth is substantial. A PQ-signed certificate with a PQ subject key might be 6-8 KB versus 1-2 KB for an ECC certificate. This affects: - **TLS handshake size**: More bytes on the wire. Initial handshake latency goes up modestly. - **Embedded systems**: 8 KB certificate may not fit in the flash budget of small IoT devices. - **Certificate transparency**: CT logs need to handle larger entries, see [certificate transparency PQC](certificate-transparency-pqc.md). - **OCSP responses**: Larger PQ signatures inflate OCSP response size, see [CRL and OCSP PQC scale](crl-ocsp-pqc-scale.md). ## ACME and PQ Certificates ACME (RFC 8555) is the protocol that drives most modern certificate issuance. The IETF ACME working group has been preparing for PQC integration: - **Algorithm negotiation**: ACME clients can advertise supported algorithms. The CA selects from the supported set. - **Hybrid certificate flows**: Drafts for issuing certificates that contain both classical and PQ public keys. - **Automated rotation**: ACME's renewal model fits naturally with shorter PQ-era cryptoperiods. As of 2026, ACME PQ support is in draft and early implementation. Let's Encrypt has piloted PQC features in staging environments. DigiCert, Sectigo, and other commercial CAs have announced PQC roadmaps. Production-grade PQ ACME workflows are expected to land in 2026-2027. For organizations using ACME today (most), the migration path is: 1. **Now**: ACME with classical certificates (RSA-2048 or ECC). Update ACME client libraries to support new algorithm negotiation when available. 2. **2026-2027**: Begin issuing hybrid certificates as CAs roll out support. Test in non-production first. 3. **2028+**: Full PQ certificates as the default for new deployments. ## Validity Periods Are Getting Shorter Independent of PQC, certificate validity periods are getting shorter. The CA/Browser Forum has approved a phased reduction: - **2024-2025**: 398 days max (current). - **2026**: 200 days max (effective March 2026). - **2027**: 100 days max. - **2027 H2 / 2028**: 47 days max (proposed). - **Possible 2029+**: 10 days max. Browsers (Chrome especially) have driven this with the argument that shorter certs limit exposure from compromised keys and force automation. Apple has made similar moves. For PQ migration, shorter validity periods are good news. They mean: - **Smaller migration cohort at each step**. Instead of a 398-day window where old and new certs coexist, you have a 47-day or 10-day window. - **Forced automation**. Manual cert management is impossible at 10-day validity. ACME or equivalent automation becomes mandatory. - **More opportunities to refresh algorithm choices**. Each renewal is a chance to upgrade. The bad news is operational pressure. Your renewal pipeline needs to be reliable enough to issue and deploy a new cert every 10 days without human intervention. ## CA Roadmaps for PQC The major public CAs as of 2026: - **Let's Encrypt**: Piloting hybrid PQ certs in staging. Production roadmap unannounced. - **DigiCert**: Multiple announcements about PQC products. Quantum-safe TLS preview customers. - **Sectigo**: PQC certificates available for enterprise customers. - **GlobalSign**: PQC announcements, products in development. - **Entrust**: PQC integration with enterprise PKI, particularly hybrid certificates. - **Google Trust Services**: PQC integration via Cloud KMS. For internal CAs, the product landscape: - **Microsoft Active Directory Certificate Services**: PQC support tracking Microsoft's Windows Server roadmap. Expect 2026-2027 rollout. - **HashiCorp Vault PKI**: PQC support landing in Vault Enterprise. - **Smallstep**: ACME-driven internal CA, PQC support tracking ACME standards. - **EJBCA**: Open-source CA software, has been adding PQC support iteratively. ## CNSA 2.0 and PQC Certificates NSA's Commercial National Security Algorithm Suite 2.0 specifies PQ algorithms for U.S. national security systems. The CNSA 2.0 timeline: - **2025-2030**: Hybrid deployment phase. Both classical and PQ algorithms supported. - **By 2030**: PQ algorithms required for new deployments. Classical algorithms (RSA, ECDSA) being phased out. - **By 2035**: Classical algorithms not permitted in NSS. For federal systems and contractors, the certificate lifecycle decisions are constrained by CNSA 2.0. New PKI deployments since late 2024 should be planning for ML-DSA-65 or ML-DSA-87 as the signature algorithm, hybrid construction during transition. See [CNSA 2.0 timeline detailed](cnsa-2-0-timeline-detailed.md) for the specifics. ## Certificate Lifecycle Pipeline Recommendations A robust PQC-aware certificate pipeline includes: 1. **Inventory**: Track every certificate, where it is deployed, what algorithm it uses, and when it expires. Automated discovery via CT logs or certificate scanning. 2. **Policy**: Define which algorithms are acceptable for new issuance. Default to hybrid PQ + classical for high-value certs, plain classical only when PQ is not supported by clients. 3. **Issuance automation**: ACME or equivalent. Manual issuance does not scale to 10-day validity. 4. **Deployment automation**: The cert needs to be installed on the target system within the validity window. cert-manager (Kubernetes), Caddy, Traefik all do this natively. 5. **Renewal monitoring**: Alert on renewal failures. A failed renewal should be a paged incident, not an email that may or may not be read. 6. **Revocation**: A clear playbook for revoking a compromised cert. CRL update, OCSP status, replacement cert issuance. 7. **Audit and metrics**: Quarterly review of issuance volume, failure rate, algorithm distribution. ## Composite Certificates and Algorithm Combinators LAMPS (the IETF working group on X.509 extensions) has been working on three patterns for representing PQ algorithms inside an X.509 certificate: **Pure PQ certificates**: A single SubjectPublicKeyInfo encoding ML-DSA-65 or another PQ algorithm. The signature is also a single PQ signature. Simple but breaks any verifier without PQ support. Suitable for closed ecosystems where every consumer can be upgraded together. **Hybrid via composite signatures (draft-ietf-lamps-pq-composite-sigs)**: A single new algorithm OID identifies a composite of classical + PQ. The SubjectPublicKeyInfo carries a structured object containing both keys. The signature is a structured object containing both signatures. Verification requires both to validate. This is the cleanest representation but requires every consumer to understand the composite OID. **Hybrid via dual signatures (catalyst certificates)**: One certificate carries two SubjectPublicKeyInfo fields and two signatures, one classical and one PQ, in extensions. Verifiers ignore the extensions if they do not understand them. This preserves backward compatibility at the cost of larger certificates. The Open Quantum Safe project's pioneering work on hybrid certificates uses this pattern. For most enterprise PKI deployments, composite signatures are the recommended path once LAMPS finalizes the draft (expected 2026). Catalyst certificates remain a useful interoperability bridge. ## Practical Hybrid Certificate Sizes Concrete numbers for a typical TLS server certificate with various algorithm choices: | Configuration | Public Key | Signature | Total Cert | |---|---|---|---| | ECC P-256 + ECC P-256 (current) | 64 B | 64 B | ~900 B | | RSA-2048 + RSA-2048 | 256 B | 256 B | ~1.5 KB | | ML-DSA-65 + ML-DSA-65 | 1952 B | 3309 B | ~6.5 KB | | Ed25519 + ML-DSA-65 (composite) | 1984 B | 3373 B | ~6.7 KB | | ML-DSA-87 + ML-DSA-87 | 2592 B | 4627 B | ~8.5 KB | | FN-DSA-512 + FN-DSA-512 (Falcon) | 897 B | 666 B | ~2.0 KB | | SLH-DSA-128f + SLH-DSA-128f | 32 B | 17088 B | ~17.5 KB | Falcon (FN-DSA) shows the smallest PQ footprint, which is one reason it is attractive for certificate scenarios. SLH-DSA's 17 KB signature makes it impractical for online TLS but acceptable for code signing where the certificate is fetched once. ## Frequently Asked Questions **Should I issue PQ certificates today?** For internal systems with internal trust roots, you can pilot PQ certificates. For public-facing systems, browser support is not yet universal, so hybrid is the practical choice. Most organizations are not issuing PQ certs in production yet but are preparing pipelines. **How does PQ affect TLS handshake performance?** The handshake is larger because PQ public keys and signatures are larger. End-to-end latency may increase 10-50ms in the worst case for ML-DSA-65 hybrid. CPU cost on both client and server goes up modestly. For most applications this is negligible. For high-volume edge services, it may be measurable. **What if my IoT device cannot fit a PQ certificate?** Three options. First, consider whether the device truly needs a public-key certificate at all (some IoT use shared symmetric secrets and PSK). Second, use a smaller PQ parameter set if available (ML-DSA-44 has smaller public keys than ML-DSA-65, though signatures are still substantial). Third, consider a cert-less authentication scheme (TLS PSK with shared secret distribution). **Will my old certificates need to be revoked when I migrate?** No. Existing classical certificates remain valid until their expiration. The migration is forward-looking: new certificates use PQ or hybrid algorithms. Existing certs age out naturally. **Can QNSQY use X.509 certificates?** QNSQY's `.qs` format uses its own identity and signing scheme rather than X.509. The cryptographic primitives (ML-DSA-65 + Ed25519) are similar to what X.509 certs would use, but the identity binding is QNSQY-specific. Bridge tooling can translate between QNSQY identities and X.509 certs for systems that need both. **Will the CA/Browser Forum specify PQ algorithms in baseline requirements?** Eventually, yes. The CA/Browser Forum maintains the Baseline Requirements which dictate what publicly trusted CAs can issue. As of early 2026, the baseline does not require PQ but does not forbid it either. Browser CT policy and Microsoft, Apple, Google root programs are likely to specify PQ requirements before the formal baseline updates. Watch the public mailing list at cabforum.org for proposed changes. **How do I run a parallel hybrid PKI in production?** Issue both classical and hybrid certificates from the same CA, with the same identity, but different OIDs. Server software with PQ awareness picks the hybrid; legacy clients pick the classical. The two certificates have separate serial numbers and revocation entries. This pattern was demonstrated in Cloudflare's PQ TLS pilots and is documented in IETF draft-ietf-pquip-pqc-policy-considerations. ## Frequently Asked Questions **Should I issue PQ certificates today?** For internal systems with internal trust roots, you can pilot PQ certificates. For public-facing systems, browser support is not yet universal, so hybrid is the practical choice. Most organizations are not issuing PQ certs in production yet but are preparing pipelines. **How does PQ affect TLS handshake performance?** The handshake is larger because PQ public keys and signatures are larger. End-to-end latency may increase 10-50ms in the worst case for ML-DSA-65 hybrid. CPU cost on both client and server goes up modestly. For most applications this is negligible. For high-volume edge services, it may be measurable. **What if my IoT device cannot fit a PQ certificate?** Three options. First, consider whether the device truly needs a public-key certificate at all (some IoT use shared symmetric secrets and PSK). Second, use a smaller PQ parameter set if available (ML-DSA-44 has smaller public keys than ML-DSA-65, though signatures are still substantial). Third, consider a cert-less authentication scheme (TLS PSK with shared secret distribution). **Will my old certificates need to be revoked when I migrate?** No. Existing classical certificates remain valid until their expiration. The migration is forward-looking: new certificates use PQ or hybrid algorithms. Existing certs age out naturally. **Can QNSQY use X.509 certificates?** QNSQY's `.qs` format uses its own identity and signing scheme rather than X.509. The cryptographic primitives (ML-DSA-65 + Ed25519) are similar to what X.509 certs would use, but the identity binding is QNSQY-specific. Bridge tooling can translate between QNSQY identities and X.509 certs for systems that need both. ## Sources 1. RFC 8555 (Automatic Certificate Management Environment, ACME) — https://datatracker.ietf.org/doc/html/rfc8555 2. CA/Browser Forum Baseline Requirements — https://cabforum.org/baseline-requirements-documents/ 3. NSA CNSA 2.0 — https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSI_CNSA_2.0_ALGORITHMS_.PDF 4. NIST IR 8547 (Transition to PQC Standards) — https://csrc.nist.gov/pubs/ir/8547/ipd 5. IETF ACME Working Group — https://datatracker.ietf.org/wg/acme/about/ 6. Let's Encrypt PQC Discussion — https://letsencrypt.org/ 7. IETF LAMPS Working Group, "draft-ietf-lamps-pq-composite-sigs" — https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/ 8. NIST FIPS 204 (ML-DSA Standard) — https://csrc.nist.gov/pubs/fips/204/final ## Related Articles - [CRL and OCSP at PQC Signature Sizes](crl-ocsp-pqc-scale.md) - [Certificate Transparency Logs and PQC](certificate-transparency-pqc.md) - [Crypto-Agility Explained](crypto-agility-explained.md) - [NIST FIPS Guide for Post-Quantum Cryptography](nist-fips-guide.md) - [Hybrid Migration Strategy: Step by Step](hybrid-migration-strategy-step-by-step.md) --- ### 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](../../pricing.html)