OCSP Service Has Reached End of Life

Original Article ↗ Hacker News Discussion ↗

Overall reaction to OCSP end-of-life

  • Many commenters are glad to see OCSP go, calling it poorly designed, privacy-hostile, and fragile (fail-open, easy to block, DoS-prone).
  • Others argue OCSP stapling was a reasonable stopgap when certificates lasted many years; with 90-day (and future 47-day) certs, its value is much lower.

OCSP vs short-lived certs and revocation

  • Strong camp: short-lived certificates (days, eventually 24h) plus Certificate Transparency (CT) are strictly better than OCSP/stapling for web TLS.
  • Counterpoint: you still can’t force early expiration after compromise; revocation (via OCSP/CRL/CRLite) is still needed, especially for longer-lived non‑TLS or offline uses.
  • One argument suggests “just reissue a cert” instead of revocation; rebuttal is that this doesn’t help when the server is compromised and still serving the old cert.

CRLs, CRLite, CRLSets, and browser behavior

  • CRLs are seen as ugly but now the main path, with scale problems (size, propagation delay, need for tricks like Bloom filters).
  • Firefox’s CRLite is viewed as a workable central revocation mechanism that doesn’t require server changes.
  • Chrome’s CRLSets are criticized as a Google‑controlled, pre-filtered blacklist that doesn’t cover all revoked certs, especially for internal CAs; defenders note this “central list” model is now common.
  • Some discussion on Firefox’s security.OCSP.require: for LE certs without OCSP URLs it likely does nothing, and Firefox already relies more on CRLite.

Certificate lifetimes, enforcement, and CT

  • Debate over whether lifetime limits are enforced by CAs or browsers:
    • Public roots: browsers enforce maximum lifetimes, and CT makes long-lived mis-issuance quickly visible.
    • Custom roots: browsers often exempt them; very long-lived internal certs can still work.
  • Extremely short lifetimes (e.g., 24h) would greatly increase CT volume and make full-log scanning difficult for smaller operators.

DNS, DANE, and centralization

  • Long thread on whether TLS PKI is “more centralized” than DNS:
    • One side: DNS (TLDs, registries) is highly centralized; governments and registries can manipulate zones.
    • Other side: WebPKI is effectively controlled by a small set of browser vendors and a CA cartel; some argue security is no better than DNS-based schemes.
  • DANE/DNSSEC is mentioned as a theoretical alternative (publishing keys/revocation in DNS), but practical deployment, middleboxes, revocation, and migration issues are seen as blocking.

Non-browser and enterprise impacts

  • Concern that non-browser clients now lack a practical revocation channel, especially in mTLS, secure boot, or enterprise/internal PKI scenarios where OCSP is still used.
  • Chrome reportedly does not check CRLs for internal CAs by default, relying instead on enterprise policy configuration.
  • Air-gapped or special-purpose environments may need CRL-only roots or other custom mechanisms.

Operational/edge notes

  • OCSP requiring port 80 sometimes clashes with “HTTPS-only” enterprise policies.
  • One person wonders if OCSP/LE changes affected HSTS behavior for a production site; others don’t provide a clear answer.
  • Some note that for Let’s Encrypt certs without OCSP URLs, OCSP-related browser settings effectively become moot.