August 22, 2026

·Quantum TLS

The 47-Day TLS Certificate: Automation as a Prerequisite for PQC

TL;DR

CA/Browser Forum Ballot SC-081, driven by the major root store programs (Apple, Google Chrome, Mozilla), steps maximum TLS certificate validity down from 398 days today to 200 days (March 2026), 100 days (March 2027), and 47 days (March 2029) — with domain-control-validation reuse windows shrinking in lockstep, down to 10 days at the final stage. At a 47-day lifespan, manual certificate provisioning (ticket-based CSR generation, human approval, manual installation) is operationally impossible at any nontrivial fleet size — ACME (RFC 8555) automation stops being a convenience and becomes a survival requirement. The connection to post-quantum cryptography is direct and non-obvious: the automation pipeline an enterprise is forced to build for 47-day rotation — algorithm-agnostic CSR generation, unattended key generation, automated CA validation, zero-touch installation — is exactly the crypto-agility infrastructure needed to swap ML-DSA (or any future replacement algorithm) fleet-wide within a single rotation cycle if a critical cryptanalytic break is found in a current NIST PQC standard. Enterprises still running manual, multi-year certificate lifecycles in 2029 will face any future algorithm break with no rotation infrastructure at all.

The Mandate: A Four-Stage Countdown

CA/Browser Forum Ballot SC-081, championed initially by Apple's root store program and subsequently adopted with Chrome and Mozilla backing, sets a fixed, published schedule for maximum TLS server certificate validity — publicly-trusted CAs that fail to comply lose root store trust, which is the actual enforcement mechanism (there is no regulatory body issuing fines; the enforcement is "your certificates stop being trusted by 3+ billion browser instances").

The DCV (Domain Control Validation) reuse column matters as much as the certificate validity column and is frequently overlooked: today, a CA can reuse a domain-control validation performed up to 398 days ago to justify reissuing a certificate without re-validating control of the domain. At the 47-day stage, that reuse window collapses to 10 days — meaning domain control must be re-proven on almost every renewal cycle, not just certificate content re-signed. This is what makes the automation requirement absolute rather than merely aggressive: a workflow that re-validates domain control by hand every 10 days, for every domain in a large estate, is not a staffing problem that can be solved by hiring more people — it's a workflow that only exists as software.

The Security Rationale

Shortening certificate lifespan is not primarily about the cryptographic strength of the key inside the certificate — it is about bounding the operational exposure window in ways revocation infrastructure has never reliably achieved.

1. Revocation Infrastructure Doesn't Work at Internet Scale

CRLs (Certificate Revocation Lists) and OCSP (Online Certificate Status Protocol) have known, long-standing reliability problems: OCSP responders are frequently unreachable or rate-limited under load, many clients "soft-fail" (accept the certificate as valid) when a revocation check times out rather than hard-failing, and CRL distribution points bloat over time. Short-lived certificates sidestep this entirely by making expiration itself the revocation mechanism — a compromised key stops being trusted within, at most, 47 days, with no dependency on any client successfully reaching a revocation endpoint at connection time.

2. Bounding the Compromise Window

If a private key is exfiltrated but the compromise is undetected, a 398-day certificate gives an attacker up to 398 days of usable impersonation capability before natural expiration forces a rotation regardless of detection. A 47-day certificate caps that same undetected-compromise window at 47 days as a hard ceiling, independent of whether the operator ever notices the breach. This is a defense-in-depth argument, not a claim that detection becomes unnecessary — it bounds the worst case.

3. Eliminating Stale Domain-Control State

Domain ownership changes: subdomains get decommissioned, DNS delegation shifts, cloud IP ranges get reassigned and reused by different tenants. A long DCV reuse window means a CA may reissue a certificate for a domain based on control validated over a year ago, under conditions that no longer hold. Shrinking DCV reuse to 10 days forces re-validation to track the current state of domain control closely enough that stale validation data stops being a meaningfully exploitable gap.

4. Forcing Automation Removes Human Error From the Critical Path

The overwhelming majority of TLS-related outages historically trace back to expired certificates that a manual or semi-manual process failed to renew in time — not to cryptographic weakness. Mandating a lifespan short enough that manual processes cannot keep up is, deliberately, a mechanism for eliminating the single most common category of TLS operational failure by making automation the only viable path.

Manual Provisioning Is Operationally Dead

Consider the arithmetic at fleet scale. A manual certificate workflow — CSR generation, internal approval ticket, CA portal submission, domain-control proof, certificate download, manual installation and reload — commonly takes 1–5 business days end-to-end even in a well-run organization. At a 47-day validity with a 10-day DCV reuse window:

An enterprise with 2,000 certificates now faces roughly 15,600 renewal events per year, each requiring domain-control re-validation within a 10-day window that does not align conveniently with business-day ticket queues. This is not a staffing problem — it is a mathematical impossibility for any process with a human in the critical path at that volume and cadence. ACME (RFC 8555) automation is the only mechanism that scales to this arithmetic.

ACME in Practice

ACME's core exchange — account registration, order creation, domain-control challenge (HTTP-01, DNS-01, or TLS-ALPN-01), CSR finalization, certificate download — is designed for exactly this unattended, high-frequency cadence:

# acme.sh — fully unattended issuance and installation, cron-driven
acme.sh --issue -d example.com -d www.example.com \
  --dns dns_cf \
  --keylength ec-256

acme.sh --install-cert -d example.com \
  --key-file /etc/nginx/ssl/example.com.key \
  --fullchain-file /etc/nginx/ssl/example.com.fullchain.crt \
  --reloadcmd "systemctl reload nginx"

# cert-manager Certificate resource — Kubernetes-native ACME automation.
# duration/renewBefore are set for a 47-day-lifespan-compatible cadence.
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com-tls
  namespace: edge
spec:
  secretName: example-com-tls
  duration: 1128h    # 47 days
  renewBefore: 720h  # renew with ~13 days of margin remaining
  dnsNames:
    - example.com
    - www.example.com
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer

The IETF's ACME Renewal Info (ARI) extension addresses a second-order problem that only emerges at this cadence: if every certificate in a large fleet renews at a fixed offset before its own expiry, mass-issued cohorts (e.g., everything provisioned during a single migration event) cluster their renewals together, creating periodic load spikes against the CA's issuance API. ARI lets the CA hand back a recommended renewal window per certificate, letting clients stagger renewal timing automatically rather than synchronizing on a fixed "renew N days before expiry" rule — a scaling accommodation that only matters once renewal frequency is high enough for clustering to be a real operational load pattern, which 47-day certificates guarantee.

The PQC Connection: Automation Is Crypto-Agility

This is the point at which the certificate-lifecycle mandate and the post-quantum migration stop being two separate initiatives and become the same infrastructure investment viewed from two angles.

What Crypto-Agility Actually Requires

"Crypto-agility" — the ability to swap a cryptographic algorithm across a fleet without a multi-year re-architecture project — decomposes into the same primitives that 47-day ACME automation already forces an organization to build:

• Unattended key generation, parameterized rather than hand-run per certificate.
• Algorithm-agnostic CSR construction — ACME's protocol layer does not care what public-key algorithm a CSR declares; it validates domain control and signs whatever CSR the client submits, subject to the CA's own policy on which algorithms it accepts.
• Zero-touch installation and service reload, so a new certificate (and, by extension, a new key algorithm inside it) takes effect without a human in the loop.
• Fleet-wide orchestration capable of tracking rotation state across thousands of independently-scheduled certificates.

None of this is PQC-specific tooling — it is exactly the tooling described in the ACME examples above, already built to survive the 47-day mandate. An organization that has already automated 47-day rotation has, as a side effect, already built the fleet-wide algorithm-swap capability a PQC (or post-PQC) migration needs.

The Concrete Failure Scenario This Prevents

Consider a hypothetical but entirely plausible scenario: NIST or the academic cryptanalysis community discovers a critical structural weakness in ML-DSA (FIPS 204) severe enough to warrant emergency deprecation, analogous to how earlier hash functions and cipher modes have been retired under active-attack pressure.

The right-hand column is not a hypothetical best case — it is the mechanical consequence of a rotation cadence that was already forced into existence by the certificate-lifespan mandate, independent of any PQC consideration at the time it was built. Swapping the key-type parameter in a cert-manager Issuer, an acme.sh --keylength flag, or an ACME client's CSR-generation call is a one-line configuration change once the surrounding automation exists; it is a fleet-wide re-architecture project when it does not.

# The entire "swap to a new PQC signature algorithm" operation, once
# 47-day automation already exists, is this one field changing:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com-tls
spec:
  privateKey:
    algorithm: MLDSA65   # was: ECDSA, RSA — swap is config, not code
  duration: 1128h
  renewBefore: 720h
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer

Why the Two Mandates Are Actually One Investment

Regulatory and industry pressure toward crypto-agility (NSM-10, CNSA 2.0, sector-specific PQC mandates) and the CA/Browser Forum's certificate-lifespan reduction are frequently discussed as separate compliance tracks with separate deadlines. They are not separate engineering problems. The lifespan mandate forces the automation investment on a fixed, externally-enforced timeline (root store trust removal is not negotiable); the PQC mandate needs exactly that automation to be operationally executable at all. Treating 47-day rotation readiness and PQC crypto-agility as a single program — rather than two parallel initiatives competing for the same engineering time — is the only sequencing that avoids building the automation pipeline twice.

Summary of Engineering Constraints

• Certificate validity falls to 200 days (March 2026), 100 days (March 2027), and 47 days (March 2029) under CA/Browser Forum Ballot SC-081, with DCV reuse windows shrinking in lockstep to 10 days at the final stage.
• Short lifespans function as passive revocation, bounding undetected-compromise exposure without depending on unreliable CRL/OCSP infrastructure.
• Manual certificate provisioning is arithmetically incompatible with 47-day/10-day cadences at any nontrivial fleet size — ACME (RFC 8555), with ARI-based renewal staggering, is the only viable operational model.
• The automation pipeline built to survive 47-day rotation — unattended keygen, algorithm-agnostic CSR generation, zero-touch install — is structurally identical to the crypto-agility infrastructure a PQC algorithm swap requires.
• Organizations should plan certificate-lifecycle automation and PQC crypto-agility as one engineering program, not two, since the former is a strict prerequisite for the latter's fleet-wide execution speed.