Decreasing Certificate Lifetimes to 45 Days

Original Article ↗ Hacker News Discussion ↗

Overall Reaction to 45‑Day Lifetimes

  • Many are supportive, seeing it as a natural continuation of “certs must be automated” and praising how Let’s Encrypt transformed WebPKI and made HTTPS ubiquitous and cheap.
  • Others strongly dislike the change, calling it bureaucratic burden/“bait” that pushes complexity onto small sites and admins who were comfortable with annual or multi‑year manual renewals.
  • Some fear lifetimes will keep shrinking (to 7 days or less), and that this will normalize users ignoring TLS errors.

Automation vs Manual Management

  • Pro‑automation experiences: once set up, ACME‑based renewal is described as essentially zero‑maintenance and vastly cheaper than manual processes; several report no TLS outages in years versus painful outages from forgotten long‑lived certs.
  • Skeptical voices argue automation “just breaks”: OS upgrades, webserver misconfig, ACME client changes, DNS API tokens, etc., can silently fail until certs are near expiry, now with half the margin.
  • Small hobby sites: some say hosting or modern servers (Caddy, built‑in ACME) make this trivial; others argue that for 1–2 static sites, 10 minutes/year of manual work was simpler and more predictable.

Enterprise, Legacy, and Special Cases

  • Enterprise products and legacy systems often lack good APIs or automation hooks; some still require manual PKCS#12 handling, restarts, or partner‑side manual updates every renewal.
  • IoT and heterogeneous fleets (old appliances, B2B integrations) are cited as especially painful; several argue these should move to private CAs where lifetimes can be longer.
  • Concern that holiday freeze/compliance windows plus shorter lifetimes reduce the safe window to notice and fix broken automation.

Rationale and Ecosystem

  • The immediate driver is CA/Browser Forum rules; commenters say the deeper reason is that revocation (CRLs/OCSP) doesn’t work well, so short lifetimes limit damage from mis‑issuance or key compromise.
  • Shorter lifetimes also reduce revocation‑list size and fit better with certificate transparency, though they increase CT log volume and operational costs.
  • Some worry about “effective single‑vendor” risk around Let’s Encrypt; others point out multiple ACME CAs (ZeroSSL, Google Trust Services, etc.), though free/unlimited terms and sales friction differ.

DNS Challenges and DNS‑PERSIST‑01

  • DNS‑based validation is important for wildcard/hidden subdomains but awkward due to DNS APIs and security of DNS tokens.
  • DNS‑PERSIST‑01 (static TXT record binding an ACME account) is seen as a big win for homelabs and enterprises that currently need tickets for every DNS change; some propose CNAME‑to‑aux‑zone patterns today.
  • A few raise security/privacy questions about putting an account identifier in DNS rather than a random token.

Certificate Pinning and Non‑Browser Clients

  • Short lifetimes complicate certificate pinning; advice trends toward:
    • Avoid pinning to public leaf or intermediate certs entirely.
    • If pinning is unavoidable, pin to keys or a private CA you control, and serve separate chains for pinned clients vs browsers.
  • There’s debate over reusing keys (easier pinning vs undermining the security intent of short‑lived certs).