SSL certificate lifetimes are going down. Dates proposed. 45 days by 2027

Browser and certificate authorities are moving to shorten HTTPS/TLS certificate lifetimes to 45 days by 2027, aiming to limit the damage from compromised keys and to force widespread automation of certificate renewal. Commenters agree shorter lifetimes improve security in theory, especially given weak revocation mechanisms, but warn of higher operational risk for poorly managed systems, IoT and offline devices, and private networks that can’t easily automate renewals. The change also raises broader concerns about growing dependence on a few major certificate authorities and browser vendors, and the shrinking space for self-signed or long-lived certificates in the modern web.

Rationale for Shorter Certificate Lifetimes

  • Main driver: revocation is unreliable; shorter lifetimes limit how long a compromised key or misissued cert can be abused.
  • Shorter windows also make it easier to punish or distrust misbehaving CAs without leaving long-lived bad certs in the wild.
  • Frequent rotation forces automation; rare, manual rotations are brittle and often cause outages when they finally happen.
  • Some in PKI have long favored very short lifetimes (e.g., ~7 days) with no revocation, but see 45 days as an incremental, more realistic step.

Operational & Usability Concerns

  • Many organizations already struggle with 1-year certs; 45 days could be painful for orgs without automation, especially large enterprises.
  • Examples given of Fortune 500s that can’t even track expiring certs today.
  • Worry that more frequent failures will train users to click through cert errors.
  • Others counter that past lifetime reductions did push successful automation and were largely absorbed by industry.

Security Effectiveness Debate

  • Some say attackers can weaponize a stolen key within hours; even 1 week helps, but 45 vs 90 days may not be a huge difference.
  • Others argue that reducing an attacker’s window from years to weeks is still a meaningful improvement, even if not perfect.
  • Discussion over key reuse: some tools rotate private keys on each renewal; others default to reusing them, weakening the benefit.

Economics of CAs and “Free” Certificates

  • Operating a public CA is expensive; “free” certs are subsidized by donors or larger organizations.
  • Concern that dominance of free CAs creates a single point of failure and long‑term funding risk.
  • Some prefer paying for longer-lived certs to avoid automation work; others argue automation is trivial scripting.

Control, Freedom, and Browser Power

  • Some object to large vendors and CAB Forum constraining cert lifetimes and accepted CAs, framing it as loss of “personal freedom.”
  • Others respond that public certs are assertions to the global user base, not a personal choice; if you want full control, use a private CA or HTTP.
  • Debate around HTTPS‑everywhere, browser hostility to self‑signed certs, and comparisons to TOFU/SSH models, especially for low‑risk local services and offline or intermittently connected systems.