SSL certificate requirements are becoming obnoxious

Original Article ↗ Hacker News Discussion ↗

Rationale for Shorter Certificate Lifetimes

  • Many commenters argue the 47‑day cap is mainly compensating for failed revocation mechanisms (CRL/OCSP often unused, huge, or privacy‑problematic).
  • Shorter lifetimes reduce window for abuse of stolen/mis‑issued certs and shrink CRLs; some note new revocation tech like CRLite but still see expiry as the simplest control.
  • Others question whether mis‑issuance and CA compromise are large enough risks compared to other vulnerabilities (e.g., memory safety), and whether the marginal gain justifies the operational pain.

Automation as Intended Outcome

  • Strong view: short lifetimes are deliberately designed to force automation; no one should be renewing public TLS certs by hand.
  • Supporters cite ACME, Certbot, Caddy, nginx/Apache modules, cloud “managed cert” offerings, and say public web PKI is “99% solved” when you control the stack.
  • Critics counter that automation itself fails, becomes “unknown cron jobs,” and that frequent expiry increases outage risk, especially when monitoring is weak.

Enterprise, Legacy, and Regulated Environments

  • Enterprise/sysadmin voices describe dozens–hundreds of endpoints (ERPs, F5s, VoIP, printers, switches, SCADA/OT gear, medical/industrial devices) with:
    • poor or no ACME support,
    • brittle TLS stacks, odd key/cipher constraints, or manual‑only UIs,
    • change‑control regimes where every cert change needs a ticket and board sign‑off.
  • For these, 47‑day cycles are seen as unrealistic and push people toward self‑signed/private CAs, or even less encryption internally. Some predict more outages and even real‑world safety impacts; others dismiss that as extreme.

Public vs Private PKI

  • Broad consensus: public Web PKI should be used only for internet‑facing services; internal systems should migrate to private CAs or tools like Vault/AD CS/ACME‑like internal services.
  • Objection: getting all clients/devices to trust a private CA is itself painful, especially for old or proprietary hardware.

Multi‑Perspective Validation and Market Effects

  • MPIC (multiple “network perspectives” for validation) is discussed as a measure against BGP/DNS hijacking.
  • Some see it as reasonable and already proven by Let’s Encrypt; others frame it as raising entry barriers and cementing large CAs.

Control, Centralization, and the Web’s Direction

  • Several comments connect tighter PKI rules, CA/B decisions, and browser policy to broader centralization and potential censorship or de‑facto forcing into big clouds.
  • Others respond that DNS and app stores are already stronger control points, and that certificate automation is a justified baseline security requirement, not yet an abuse of power.