https://f000.backblazeb2.com/file/0011public/Photo-2025-09-1...
Might be EOL in some theoretical sense, but by turning it off they're ignoring reality. I know some organizations think this is the way to push standards forward. But to me it seems pretty irresponsible.
Edit: I believe OCSP is tried, but silently ignored if there is no reponse quickly enough.
I would say "majority" rather than "not all" browsers perform revocation checking.
We're starting to see adoption for O(days) now but I imagine that the lifetime will continue to decrease to some minimum O(hours) in the years to come.
Compared to what? 12MB JavaScript bundles and autoplay videos? Do CDNs still exist?
There's a finite number of CAs and browsers can be expected to perform caching. Delta CRLs also exist and the CAs can decline to include expired leaf certs.
This sounds like a made up problem that was solved 25 years ago.
Not really sure how big of a problem a list could be?
And if I cache the information that it is revoked, how do I know that it's allowed again?
I could check, let's say one time per day even if I don't access that site.
In any case I'm still leaking which domains I browse and I keep trusting cached certificates until the next check.
On the other side, with short lived certificates I would be trusting a certificate for a longer time, until it expires.
Downloading a list of all certificates and their status from every CAs is probably unfeasible.
It seems that we can't escape a tradeoff between privacy and security.
The idea with OCSP-stapling is that the webserver fetches the OCSP data, caches it for TTL ~24 hours, and staples it to the HTTPS handshake. That way, the browser does not need to query the issuer's OCSP servers, avoiding both performance and privacy concerns. Revoked certificates will continue to work for up to 24 hours, but that, IMO, is within an accepted range compared to CRL that can take a lot longer.
The downside is that the HTTPS handshakes now contain a bit more data, and we want to keep this as minimal as possible.
- Let's Encrypt: doesn't support it since May 7 this year
- Buy Pass: No longer offers free certificates, probably didn't have must-staple either
- Zero SSL, I didn't find any public links to check if they sign CSRs with it.
- Google Trust Services: Same as above
- Amazon Trust: Same as above, but it probably does.
The problem with OCSP stapling is that it either the client has to fall back to doing OCSP checking itself if the server doesn't staple the signature, which has its own problems[1], or enough servers need to support ocsp stapling that the client can just reject connections that don't include it. And unfortunately, there was never a significant uptake for servers, partly because there wasn't really any incentive to implement OCSP stapling. Maybe if there was a TLS 2.0 (or some other standard) that required OCSP stapling and had other benefits as well, it could work.
[1]: the biggest problem with non-stapled OCSP is what to do if you don't get a response for the ocsp request. If you fail open, an attacker can intercept the request to prevent you from knowing the cert is revoked, but if you fail closed, then any issue with the connection to the ocsp server results in loss of service. And then there are also issues with additional latency to wait for the ocsp response, privacy leaks from the ocsp requests, etc.
How so? Doesn't revocation have to be done by the same entity that issued the certificate?
However, this page, shows perfectly, so there must have been some differences between this and the domain I remember. Unfortunately, my domain has long since been reissued and I can't reproduce the block. The block also occurred in the latest Thunderbird for windows 7 interestingly.
Let's encrypt already EOLd OCSP
The whole chain of trust model is that your browser vouches for an authority that vouches for a website that everything is legit.
You can't just ducktape on an idea like that cert for "www.xyz" is totally legit unless I takesies-backies'd my vouch at some point, so just double-check.
If you want that sort of "continuous" trust scheme, then what makes more sense is something like having short-lived certificates.
This loads fine in Safari on iOS 26 lol.
I always thought Chrome didn't block them and that revocation was pretty much dead.
Edit: Their details are not correct: They claim the browsers would not trust it, but in practice they do.
But their details ARE correct. It says the certificate is revoked, which it is. It's up to the individual browser to act upon that (which most don't).
Certificates can be revoked with various revocation reasons, however, it looks this one has no specific revocation reason listed in the CRL. For a certificate that was revoked with a reason of "Key Compromise", things would be different, and most browsers would probably reject it.
Firefox has a project (crlite) that uses bloom filters to make crls more practical, but it is still experimental. I think we are a long ways out from the technology being widely used across the industry.
It turns out it is easier to significantly reduce the validity time of webpki certs than solve the problem of distributing distrbuting a list of revoked certificates. Although the former actually helps a lot with the latter, as it reduces the size of said list.
Dylan16807•2h ago