They are calibrated for organizations/users that have higher consequences for mis-issuance and revocation delay than someone’s holiday blog, but I don’t think they’re behaving selfishly or irrationally in this instance. There are meaningful security benefits to users if certificate lifetimes are short and revocation lists are short, and for the most part public PKI is only as strong as the weakest CA.
OCSP (with stapling) was an attempt to get these benefits with less disruption, but it failed for the same reason this change is painful: server operators don’t want to have to configure anything for any reason ever.
> 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?
You hit on a good point... a better solution would be a special class of certificates, sort of like EV certs, where the lifetime is extremely short, specifically for the sorts of enterprises, like banks, that need that level of care. Granted, most banks can't get their SPF, DKIM, and DMARC correct for years at a time, so they would definitely find a way to screw that up.
The problem with that solution is that EV already showed that a two-class system of certificates that only really differ in slight UI hints is not useful. Normies never had any idea what the green bar means, and even unusually savvy users are not likely to remember whether a particular website had an EV certificate or not last time they visited.