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.
—though I’m not sure how this fits in with https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co... which said “we will be disabling OCSP for domain validated certificates in Firefox 142”. This is a stunningly fuzzy area where the true and accurate information is difficult to come by.
—⁂—
¹ https://searchfox.org/firefox-main/source/modules/libpref/in.... Actually, on Android it defaults to 2, which skips OCSP on DV certificates, which is almost all these days.
² https://searchfox.org/firefox-main/source/modules/libpref/in...
Doesn't seem all that fuzzy to me? Domain validated certificates are certificates where only domain name ownership is verified (like ACME does for Let's Encrypt). So it seems starting with Firefox 142 OCSP would be disabled by default for Let's Encrypt certificates.
Edit: I believe OCSP is tried, but silently ignored if there is no reponse quickly enough.
Edit: It seems to be enabled by default! I've been using Firefox for as long as I remember, and don't setup Firefox afresh frequently.
Not really, since they now offer six-day certs, which makes revocation effectively irrelevant: https://letsencrypt.org/docs/profiles/#shortlived
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.
How do you know it is allowed again? Because it responds with a new certificate, that isn't revoked...
You are not leaking anything. You are just downloading a list of revoked domains. Regardless of whether you are visiting them or not.
IETF will be gradually reducing maximum length of public certs to 47 days. I expect this will help some of the issue since expired certs can be removed from the list.
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.
web servers can refresh OCSP responses in the background and cache valid responses to add some tolerance against temporarily downtimes in the OCSP server.
It's really a chicken and egg problem. Browsers don't want to support must-staple because not enough servers use it. And servers don't use it, because browsers don't require it (or even implement it). And now CAs don't support it, because hardly anyone was using it.
Now if CAs started requiring must-staple, that might push it into widespread use. But that would cause a lot of disruption.
As for server implementaions. Most servers, sure it isn't that much harder to use `must-staple`, if you are already doing ocsp stapling. But most servers don't do the stapling at all, because there isn't a strong reason to, and you need to set up a system to periodically fetch and cache the OCSP signatures, and whatever system you use to terminate TLS needs to support it.
Short lived certificates are definitely the better way forward.
24 hour certificates will add a significantly more load on CAs, a lot more than maintaining an OCSP responder.
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.
I'm using the term "revocation list" loosely, as it can be as simple as a list of public keys to distrust. Client software can use any revocation list they want, AFAIK.
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.
In the very near future, CAs are going to start embedding signed CT timestamps from "static CT" logs [2]. Once that happens, the CRLite backend will be aware of certificates within minutes of issuance.
[1] The wyvern2025h2 shard had an outage last week, which is also part of the problem here https://groups.google.com/a/chromium.org/g/ct-policy/c/XpmIf....
Might as well not even revoke it…
If a CA issues a certificate to the wrong entity, they won’t have knowledge of a key compromise as there is no such thing in this case — they only know that they issued something wrong…
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.
Let's Encrypt is now offering a profile for 6-day certificates: https://letsencrypt.org/docs/profiles/#shortlived
With such short-lived certificates, revocation effectively becomes a non-issue.
[0]: OCSP Stapling (esp. with Must-Staple) is actually pretty effective at distributing revocation information in a timely, secure, private manner. There were no real downsides to the spec, which is why Caddy has supported automatic OCSP stapling since, gosh, I think 2016 or so. The problem is that most other web servers didn't -- and still don't -- implement it well [1], making OCSP (without the stapling) a persistent privacy problem. Additionally, many client vendors want to choose what certificates count as "revoked" now, so they use their own CRLs, making OCSP entirely useless, since they only check their own CRLs.
[1]: https://gist.github.com/sleevi/5efe9ef98961ecfb4da8 -- most servers have such a bad implementation of OCSP stapling that it makes sites less reliable, not more.
GrapheneOS used https://github.com/tomwassenberg/certbot-ocsp-fetcher for years to provide reliable OCSP stapling for nginx prior to Let's Encrypt dropping OCSP support. We used Must-Staple through that for years.
TLS ticket key rotation also generally needs to be handled externally in a noswap tmpfs to avoid the keys being lost when restarting service, especially if syncing them across multiple nodes providing the same service is desired. Syncing them across nodes also allows preserving them across reboots while still only having them in-memory.
> Let's Encrypt is now offering a profile for 6-day certificates: https://letsencrypt.org/docs/profiles/#shortlived
Only the default classic and opt-in tlsserver profiles are available. The allowlist mentioned there doesn't really seem to exist yet. The tlsserver profile has the same changes as shortlived without dropping 90 days to 160 hours. Both tlsserver and shortlived drop support for clients without SNI support which are unfortunately still very common for non-web usage. We found we can't deploy tlsserver for our SMTP federation (port 25) or SUPL server without having a fallback certificate for clients without SNI support. Since shortlived drops non-SNI client support, not everyone will be able to use it. It would be nice if there were 2 variants of it instead since client functionality is typically not within the control of servers.
Let's Encrypt dropped OCSP support before they had the replacement of short-lived certificates deployed. It would have been nice if OCSP support was only dropped after shortlived was enabled for production usage, but it's too late for that now. If it was possible to start using shortlived today, we would.
https://crt.sh/?id=20924740030
$ curl -s http://r13.c.lencr.org/105.crl | openssl crl -noout -text | grep -A1 899DE8
Serial Number: 055B8B1F23D5BCF09DD8E9CAF8798F899DE8
Revocation Date: Sep 10 16:00:16 2025 GMT
Dylan16807•4mo ago