Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> OCSP failed for the same reason this change is painful: server operators don’t want to have to configure anything for any reason ever.

OCSP is going end-of-life because it makes it too easy to track users.

From Lets Encrypt[1]:

We ended support for OCSP primarily because it represents a considerable risk to privacy on the Internet. When someone visits a website using a browser or other software that checks for certificate revocation via OCSP, the Certificate Authority (CA) operating the OCSP responder immediately becomes aware of which website is being visited from that visitor’s particular IP address. Even when a CA intentionally does not retain this information, as is the case with Let’s Encrypt, it could accidentally be retained or CAs could be legally compelled to collect it. CRLs do not have this issue.

[1]: https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-...





Client-side OCSP makes it too easy to track users. OCSP stapling largely solves that (plus the latency/fail-open issues) by having the server staple a recent OCSP response to the certificate during TLS negotiation. If OCSP stapling had succeeded, the privacy issues would have mostly disappeared (you could track that a server was serving traffic for a domain, but not the users).

OCSP stapling adds two more signatures to the TLS handshake. Bad enough with RSA keys but post-quantum signatures are much larger. OCSP stapling was always a band-aid.

If the server must automatically reach out to retrieve a new OCSP response for stapling every 7 days, why not just get automatically a whole new certificate which is simpler and results in a lots less data on the wire for every TLS connection?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: