TLS certificate lifetimes will officially reduce to 47 days

Original Article ↗ Hacker News Discussion ↗

Overall reaction

  • Thread is sharply polarized.
  • Supporters see this as a natural continuation of the last decade’s move toward automation and shorter lifetimes.
  • Opponents call it “catastrophic”, unnecessary “security busywork”, and accuse the CA/B Forum and browsers of ignoring operational reality and concentrating power.

Security rationale and claimed benefits

  • Shorter lifetimes reduce exposure from:
    • Mis‑issued or compromised certificates that can’t be reliably revoked.
    • Stale validation data (domain control, organization info, old DCV methods).
    • Long‑lived certs obtained via BGP hijack or past CA incidents.
  • Revocation (OCSP/CRL) is widely seen as broken or inconsistently checked; short lifetimes are framed as a de‑facto revocation mechanism.
  • Some argue this also reduces CA “too big to fail” risk: misbehaving CAs’ impact is naturally time‑limited.

Operational and automation impacts

  • Pro‑change side:
    • “If a human can do it, a machine can” – treat this as a forcing function to adopt ACME, monitoring, and proper PKI hygiene.
    • Believe most sites can use free ACME clients, reverse proxies (Caddy, Traefik), or managed CDNs/ALBs to automate.
  • Anti‑change side:
    • Many products (IIS, F5, NAS, IPMI, older appliances) lack first‑class ACME; workarounds are brittle glue scripts and REST hacks.
    • Large shops already struggle with 1‑year certs; 47‑day cycles increase failure modes (especially across weekends, vacations, long chains of approvals).
    • Multi‑server deployments, non‑HTTP services, and segmented networks complicate automation.

Small orgs, legacy systems, and internal PKI

  • Concern that this disproportionately hurts small orgs and “off‑the‑shelf” users, pushing them toward big cloud vendors and managed platforms.
  • Many enterprises are already moving most internal services to private CAs with long‑lived certs; some see that as the desired outcome.
  • Others note running an internal CA and rolling it out across mixed fleets (desktops, phones, containers, IoT) is non‑trivial.

Self‑hosting and “grassroots internet”

  • Some fear this accelerates the decline of DIY hosting and independent sites, making “simple home server + static HTML” less viable and increasing dependence on third‑party platforms.
  • Counterargument: ACME + modern proxies actually make HTTPS easier than the pre‑Let’s‑Encrypt era of expensive, fax‑verified multi‑year certs.

Identity vs encryption and alternatives

  • Long subthread debates whether TLS’s real value is encryption alone or authenticated identity.
  • Several argue unauthenticated encryption (self‑signed, TOFU) is fine for many small/local use cases and browsers are too hostile to it.
  • Others reply that on hostile networks (coffee‑shop Wi‑Fi, ISPs) MITM is the primary threat; without identity, encryption is easily intercepted.
  • Alternatives like DANE/DNSSEC, SSH‑style TOFU, local CAs, and special “intranet” trust models are discussed but seen as poorly deployed or lacking browser support.

Revocation, short‑lived certs, and CT

  • Broad agreement that OCSP and CRLs don’t work well in practice; many clients don’t check them consistently.
  • Short‑lived certs (down to 7 days, even 6‑day options) are presented as a way to bypass revocation altogether at the cost of heavier infrastructure load (CT logs, CAs, HSMs).
  • Some worry about the “purity spiral”: effort poured into certificate hygiene instead of larger, more common security problems.

Governance, incentives, and “endgame” concerns

  • Multiple comments note this change was driven primarily by browsers (especially Apple/Google) with CAs concurring; browsers represent billions of relying parties.
  • Critics argue the decision externalizes costs onto operators while browsers/large CAs bear little downside. Some raise legal‑exposure and central‑control theories; defenders call such claims “silly” or conspiratorial.
  • Speculation on the “endgame”: very short lifetimes (hours or minutes) or even per‑connection online validation is raised and generally dismissed as operationally and audit‑wise untenable, though many expect further reductions after 2029.