Upcoming Changes to Let's Encrypt Certificates

Original Article ↗ Hacker News Discussion ↗

Centralization and Single Point of Failure

  • Many commenters worry that much shorter lifetimes make ACME CAs, especially Let’s Encrypt, critical infrastructure: if an ACME CA is down for days, large parts of the web could lose valid certs.
  • Others argue this risk already exists, and shortening lifetimes doesn’t specifically increase LE’s centrality; ACME is an open standard and multiple free/paid ACME CAs exist (ZeroSSL, Google, SSL.com, Actalis, Sectigo, etc.).
  • Some suggest using multiple CAA records / multiple CAs for redundancy; Caddy’s multi-CA behavior is cited as a model.
  • There’s geopolitical concern and calls for a strong EU-based nonprofit CA as a strategic backup, but also skepticism that any WebPKI approach avoids central choke points.

45‑Day Lifetimes: Rationale vs Criticism

  • The 45‑day move is widely recognized as a CA/Browser Forum mandate (max 47 days), not an LE choice; all public CAs will be forced into this, on a phased timeline (default 64 days in 2027, 45 in 2028).
  • Pro‑change arguments:
    • Short lifetimes partially substitute for broken revocation (e.g., BygoneSSL / stale certs after domain ownership changes).
    • They strongly encourage automation, reducing human error around annual renewals.
  • Critical views:
    • More renewals mean more failure points (automation bugs, NTP issues, legacy systems that can’t reload certs, devices stuck with old trust stores).
    • Old/archival and low-maintenance sites may simply disappear rather than be modernized.
    • Some see this as “policy ratcheting” by unaccountable browser vendors, solving CA misissuance by offloading risk to operators.

Automation, Internal Uses, and Tooling

  • Many report ACME renewals “just work”; others say certbot and scripting are fragile, requiring manual intervention every few cycles.
  • Internal services (IRC, SMTP, VPNs, intranet apps, IoT, “offline” LAN services) are highlighted as hard to fit into HTTP‑01/DNS‑01, especially where DNS APIs are coarse‑grained or inaccessible.
  • Several people recommend private PKI for mTLS / internal auth; relying on public WebPKI for client certs or internal auth is called risky. LE dropping client‑auth EKU is controversial but defended as safer separation of concerns.
  • New ideas mentioned: DNS‑PERSIST‑01, DANE, and “real‑time” DNS‑tied trust, or RPKI‑style policies, but none are mainstream.

Broader Web and Governance Concerns

  • Some lament that “TLS everywhere” plus short lifetimes turn every site into something that must be continually re‑blessed by a semi‑central authority, which can fail or be politically influenced.
  • Others counter that TLS is non‑optional due to real abuses (ISP injection, ad/malware, STARTTLS stripping) and that integrity for even simple blogs matters.
  • There is broad unease about the CA/Browser Forum power dynamic (dominated by major browsers), but disagreement on whether the net effect of these changes is positive or harmful.