Context: WebPKI revocation is broken. It didn't have to be [0], but it always has been, and likely always will be, now that the industry is moving to short-lived certificates.
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.
For the people wondering why this does not show up as revoked in their browser:
I believe the way the current revocation systems work is that browsers compile centralized lists of revoked certificates, but they do not contain all revoked certs, but only ones that indicate some form of security issue.
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 / CRLite includes all revocations. The issue with this particular certificate is that the CRLite backend is behind on ingesting both of the CT logs that it appears in (Digicert wyvern2025h2 [1] and Let's Encrypt oak2025h2). So from CRLite's perspective the certificate doesn't exist yet.
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.
What would be the point of accepting a certificate that was revoked for non-security reasons?
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…
I believe I remember reading that chrome has a seperate system for revoking CA certificates, where they have to do a manual rollout, but propagation time is pretty fast.
Seems rather problematic that a cert that appears to have been revoked 5 days ago isn’t recognized as revoked by virtually any browser. Is this an OCSP-related issue or do browsers actually do a bad job at checking for revocation?
I was a big fan of OCSP-stapling and must-staple. Both of which are slowly being discouraged; LetsEncrypt refuses to issue must-staple certificates since a few months ago, and I think they are shutting down OCSP servers, if not shut down already.
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.
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.
If the certificate was issued with must-staple flag, then the server can refuse to connect if the handshake did not include an OCSP response.
web servers can refresh OCSP responses in the background and cache valid responses to add some tolerance against temporarily downtimes in the OCSP server.
Right, but the vast majoriry of servers don't use must-staple certs. So browsers would need to do something (even if that something is not checking revocations) for all the other connections anyway.
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.
If you're willing to put in the effort to implement OCSP in the first place, why not take the couple percent extra time to add must-staple support? This seems like it would have been a very easy to solve chicken and egg problem.
Browsers and CAs did support `must-staple`. Then they decided to drop support for OCSP altogether, in part because not enough servers were using must-staple (or ocsp stapling at all).
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.
Checking for revocation doesn't scale and has serious privacy implications. There are two ways to do revocation: CRL and OCSP. CRL is a list that becomes huge over time - hosting it would require massive amounts of bandwidth and clients would need to download a lot of extra data. OSCP is more like a query API - did this cert expire? The problem is you need to make that query for each visit and you leak your IP address when you do that query. The hoster would need to provide capacity to run those queries and serve the result. For each visit you'd need to pay a few round-trips worth of delay before showing the content, sometimes while part of the content is downloaded: you download example.com, which has some CSS which is hosted at static.example.com, and the website redirects you to m.example.com which is the mobile version after running some JavaScript which detects the browser capabilities.
So the answer then is just much shorter-lived certs? I could definitely still see the need for an immediate revocation to be recognized near-instantaneously. Or in practice is that ultimately not necessary?
Yes, I think short-lived certs are ultimately where we're headed.
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.
I dread supporting O(hours). Clients often have wrong clocks. I've seen some client systems that enforced 'Not Before' and interpreted the datetime as local time and there were many users of that platform in the Americas; and my CA at the time insisted that Not Before was the time of issuance... lots of fun deciding how long to keep using a revoked certificate to balance the users with working revocation vs the users with broken Not Before checking. The client system I'm aware of is very dead, but maybe other systems managed similar.
Ironically this ends up putting a ton more load on the issuers, which some others have pointed out is why revocation doesn’t scale well (other than privacy concerns, which are valid).
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.
> CRL is a list that becomes huge over time - hosting it would require massive amounts of bandwidth and clients would need to download a lot of extra data.
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.
Again, if you need to revoke a certificate, it means something terrible happened - someone compromised your server and your website has a good chance to be impersonated by 3rd parties. In all the other cases, you just let the old cert expire. You likely don't want people finding out about the revocation 12-24 hours later.
Let's see. I can cache the information that example.com is valid up to May 31 2026, but then how do I know that it gets revoked on any day before that date?
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.
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.
It’s enabled in Firefox (pref security.OCSP.enabled defaults to 1¹), but not forced (pref security.OCSP.require defaults to false²). I believe Safari behaves the same way.
—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.
> “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.
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.
The pref defaults don’t match that narrative. The blog post could be wrong, the prefs could have been repurposed without being renamed, something else… and the whole thing is very difficult to inspect.
Several years ago, I saw some documentation about specifying the locations of CRLs in some proxy software. My first thought was "surely I have some of those on the system for web PKI". I was wrong. That sent me down a deep dark rabbit hole of how revocations are normally handled, at the bottom of which was the conclusion that most software does nothing, because it is just too hard.
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.
It's also literally a centralized trust model though. You know how the saying goes: if you're going to be a criminal, you may as well be the best one in town.
Revocation has many meanings. No central revocation authority is actually enforced by the BRs, as far as I know. Clients can do whatever they want. The CA can say a cert is revoked but no one has to care. Clients can also say a cert is revoked and then all their client instances start rejecting it. Most clients work this way now, like Safari -- they just distribute their own CRLs.
I've always felt that the browser vendor + CA model was bad but this is next level embarrassing. How is the very root of trust in the internet so... untrustworthy?
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.
That's because revocation checking (if it ocsp) is something that sounds good at a glance but is actually quite a bad idea. Not doing live revocation checking is definitely the right choice for browsers to make. It doesn't protect against real threats and is terrible for privacy.
Sometime last summer, I encountered a domain which WAS revoked.
I was and am using Firefox, roughly v120, in Ubuntu and it threw up an unskippable error page, similar to those self signed pages in chrome.
I did turn it off for hahas, in about:config, i believe it was an OCSP setting,
security.OCSP.enabled to let me view the page.
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.
Certificate revocation has always been broken in practice. OCSP is slow. It creates privacy issues. CRL distribution is a mess. Honestly most implementations just fail open when they can't reach the revocation server. The real problem is that revocation assumes a perfect world where compromised certificates are immediately reported and revoked. In reality, most breaches go undetected for months…
is this specific page supposed to show as revoked? its not showing as revoked for me in firefox, but https://revoked.badssl.com/does so i know my browser is doing revocation checking. I'm curious whats happening here.
revoked.badssl.com is showing up for me in Firefox on mobile just fine, so perhaps there is some nondeterminism here in some way? To be fair, this would be even more bizarre...
This page is to demonstrate that revocation is broken. There is no central revocation authority. Anyone can publish a revocation list, whether it's a CA or client vendors or Joe from his mom's basement.
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.
Given the mentions of Chrome, Safari, Firefox, and the usual.
I would say "majority" rather than "not all" browsers perform revocation checking.
[1]: https://gs.statcounter.com/browser-market-share
Context: WebPKI revocation is broken. It didn't have to be [0], but it always has been, and likely always will be, now that the industry is moving to short-lived certificates.
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.
For the people wondering why this does not show up as revoked in their browser: I believe the way the current revocation systems work is that browsers compile centralized lists of revoked certificates, but they do not contain all revoked certs, but only ones that indicate some form of security issue.
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 / CRLite includes all revocations. The issue with this particular certificate is that the CRLite backend is behind on ingesting both of the CT logs that it appears in (Digicert wyvern2025h2 [1] and Let's Encrypt oak2025h2). So from CRLite's perspective the certificate doesn't exist yet.
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....
[2] https://github.com/C2SP/C2SP/blob/main/static-ct-api.md
Actually, the story in this case is a bit more complicated than I initially thought: https://github.com/mozilla/crlite/issues/367.
What would be the point of accepting a certificate that was revoked for non-security reasons?
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…
I believe I remember reading that chrome has a seperate system for revoking CA certificates, where they have to do a manual rollout, but propagation time is pretty fast.
[citation needed]
https://dadrian.io/blog/posts/revocation-aint-no-thang/
The citation is that that is Hanno Böck.
Seems rather problematic that a cert that appears to have been revoked 5 days ago isn’t recognized as revoked by virtually any browser. Is this an OCSP-related issue or do browsers actually do a bad job at checking for revocation?
I was a big fan of OCSP-stapling and must-staple. Both of which are slowly being discouraged; LetsEncrypt refuses to issue must-staple certificates since a few months ago, and I think they are shutting down OCSP servers, if not shut down already.
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.
I don't think any browsers still support OCSP.
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.
If the certificate was issued with must-staple flag, then the server can refuse to connect if the handshake did not include an OCSP response.
web servers can refresh OCSP responses in the background and cache valid responses to add some tolerance against temporarily downtimes in the OCSP server.
Right, but the vast majoriry of servers don't use must-staple certs. So browsers would need to do something (even if that something is not checking revocations) for all the other connections anyway.
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.
If you're willing to put in the effort to implement OCSP in the first place, why not take the couple percent extra time to add must-staple support? This seems like it would have been a very easy to solve chicken and egg problem.
Browsers and CAs did support `must-staple`. Then they decided to drop support for OCSP altogether, in part because not enough servers were using must-staple (or ocsp stapling at all).
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.
I wonder if any free certificate issuers still support Must-Staple?
I don't think so.
- 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.
How is this actually better (or conceptually even different) than just having the issuer's servers issue new certificates that only last 24 hours?
It's not better.
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.
Checking for revocation doesn't scale and has serious privacy implications. There are two ways to do revocation: CRL and OCSP. CRL is a list that becomes huge over time - hosting it would require massive amounts of bandwidth and clients would need to download a lot of extra data. OSCP is more like a query API - did this cert expire? The problem is you need to make that query for each visit and you leak your IP address when you do that query. The hoster would need to provide capacity to run those queries and serve the result. For each visit you'd need to pay a few round-trips worth of delay before showing the content, sometimes while part of the content is downloaded: you download example.com, which has some CSS which is hosted at static.example.com, and the website redirects you to m.example.com which is the mobile version after running some JavaScript which detects the browser capabilities.
So the answer then is just much shorter-lived certs? I could definitely still see the need for an immediate revocation to be recognized near-instantaneously. Or in practice is that ultimately not necessary?
Yes, I think short-lived certs are ultimately where we're headed.
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.
I dread supporting O(hours). Clients often have wrong clocks. I've seen some client systems that enforced 'Not Before' and interpreted the datetime as local time and there were many users of that platform in the Americas; and my CA at the time insisted that Not Before was the time of issuance... lots of fun deciding how long to keep using a revoked certificate to balance the users with working revocation vs the users with broken Not Before checking. The client system I'm aware of is very dead, but maybe other systems managed similar.
Ironically this ends up putting a ton more load on the issuers, which some others have pointed out is why revocation doesn’t scale well (other than privacy concerns, which are valid).
> CRL is a list that becomes huge over time
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.
> CRL is a list that becomes huge over time - hosting it would require massive amounts of bandwidth and clients would need to download a lot of extra data.
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.
If you cache the revocation list, you lose all the benefits of instant revocation making the whole process pointless.
OCSP is dead. We don't have that luxury anymore. By caching I meant for 12-24 hrs.
Again, if you need to revoke a certificate, it means something terrible happened - someone compromised your server and your website has a good chance to be impersonated by 3rd parties. In all the other cases, you just let the old cert expire. You likely don't want people finding out about the revocation 12-24 hours later.
OCSP-stapling seemed to be fine with 24-48 hour client-side caching, though.
You could of course cache the list, only download whatever was new from a specific date. Short-lived certs would vastly reduce the list as well.
Not really sure how big of a problem a list could be?
Let's see. I can cache the information that example.com is valid up to May 31 2026, but then how do I know that it gets revoked on any day before that date?
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.
You cache the revocation list, no? If it is in the list it is revoked...
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.
If you don't do a job at all, have you done a bad job?
So far, I've tried this in, chrome, firefox, safari, arc and comet. loads in all of them
Sounds like letsencrypt is being quite premature by turning off OCSP. https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-...
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.
> Sounds like letsencrypt is being quite premature by turning off OCSP.
Not really, since they now offer six-day certs, which makes revocation effectively irrelevant: https://letsencrypt.org/docs/profiles/#shortlived
As far as I know OCSP isn't enabled by default in any browser.
It’s enabled in Firefox (pref security.OCSP.enabled defaults to 1¹), but not forced (pref security.OCSP.require defaults to false²). I believe Safari behaves the same way.
—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...
> “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.
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.
The pref defaults don’t match that narrative. The blog post could be wrong, the prefs could have been repurposed without being renamed, something else… and the whole thing is very difficult to inspect.
Do all other major CAs offer OCSP? Are all major browsers performing the check? I vaguely remember Firefox doesn't. Not at my desk now to check it...
Edit: I believe OCSP is tried, but silently ignored if there is no reponse quickly enough.
Firefox has a a toggle `Query OCSP responder servers to confirm the current validity of certificates`, which is turned off by default.
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.
[dead]
Yes, because this is not a security-relevant revocation.
How do you even _get_ it to show as revoked? I tried FF, Chrome, Safari, curl, wget.
Several years ago, I saw some documentation about specifying the locations of CRLs in some proxy software. My first thought was "surely I have some of those on the system for web PKI". I was wrong. That sent me down a deep dark rabbit hole of how revocations are normally handled, at the bottom of which was the conclusion that most software does nothing, because it is just too hard.
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.
"Not all" is quite an understatement.
Don't forget revocation checking = more centralised control, although they seem to have gone with very-short-lived certificates instead.
It's also literally a centralized trust model though. You know how the saying goes: if you're going to be a criminal, you may as well be the best one in town.
Revocation has many meanings. No central revocation authority is actually enforced by the BRs, as far as I know. Clients can do whatever they want. The CA can say a cert is revoked but no one has to care. Clients can also say a cert is revoked and then all their client instances start rejecting it. Most clients work this way now, like Safari -- they just distribute their own CRLs.
> Don't forget revocation checking = more centralised contro
How so? Doesn't revocation have to be done by the same entity that issued the certificate?
I've always felt that the browser vendor + CA model was bad but this is next level embarrassing. How is the very root of trust in the internet so... untrustworthy?
Revocation seems really nasty to deal with.
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.
I'm on Windows 11 (25H2 / 26220), and with Chrome (140), Edge (141) and Firefox (142) I wasn't able to find a browser that would show this as revoked.
Safari on iOS 26 certainly doesn’t show this page as revoked.
fwiw iOS happily displays the cert as very valid
https://f000.backblazeb2.com/file/0011public/Photo-2025-09-1...
That's because Apple uses their own CRLs, pretty much exclusively.
That's because revocation checking (if it ocsp) is something that sounds good at a glance but is actually quite a bad idea. Not doing live revocation checking is definitely the right choice for browsers to make. It doesn't protect against real threats and is terrible for privacy.
For those (i.e. me) who were concerned that the cert wasn't actually revoked, it is.
https://crt.sh/?id=20924740030
Sometime last summer, I encountered a domain which WAS revoked. I was and am using Firefox, roughly v120, in Ubuntu and it threw up an unskippable error page, similar to those self signed pages in chrome. I did turn it off for hahas, in about:config, i believe it was an OCSP setting, security.OCSP.enabled to let me view the page.
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.
OCSP is deprecated for CRLs
Let's encrypt already EOLd OCSP
Certificate revocation has always been broken in practice. OCSP is slow. It creates privacy issues. CRL distribution is a mess. Honestly most implementations just fail open when they can't reach the revocation server. The real problem is that revocation assumes a perfect world where compromised certificates are immediately reported and revoked. In reality, most breaches go undetected for months…
is this specific page supposed to show as revoked? its not showing as revoked for me in firefox, but https://revoked.badssl.com/ does so i know my browser is doing revocation checking. I'm curious whats happening here.
> https://revoked.badssl.com
This loads fine in Safari on iOS 26 lol.
Also in Fennec 129...
revoked.badssl.com is showing up for me in Firefox on mobile just fine, so perhaps there is some nondeterminism here in some way? To be fair, this would be even more bizarre...
Interestingly Chrome 140.0.7339.51 on Android 16 blocks it with a net::ERR_CERT_REVOKED error.
I always thought Chrome didn't block them and that revocation was pretty much dead.
To clarify, https://revoked.badssl.com/ is the one being blocked. https://revoked-isrgrootx1.letsencrypt.org/ shows just fine.
This page is to demonstrate that revocation is broken. There is no central revocation authority. Anyone can publish a revocation list, whether it's a CA or client vendors or Joe from his mom's basement.
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.
The certificate expiry is Dec 2025 so it's valid.
Details: https://www.ssllabs.com/ssltest/analyze.html?d=revoked-isrgr...
Edit: Their details are not correct: They claim the browsers would not trust it, but in practice they do.
> Their details are not correct: They claim the browsers would not trust it
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).
As part of their details they mention browser behavior. And that part is incorrect.
Is this related to https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-... ?
It’s a negative on Firefox 142, Chrome 140 and iOS Safari.
Unclear message on the page. I still don't know if the certificate is revoked or not.
https://crt.sh/?id=20924740030
Has anyone gotten it to show as revoked?