5 ms·
Not all browsers perform revocation checking
- Dylan16807 1y ago"Not all" is quite an understatement.
- Titan2189 1y agoI'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.
- zephyreon 1y agoSafari on iOS 26 certainly doesn’t show this page as revoked.
- gslin 1y agohttps://crt.sh/?id=20924740030 https://crt.sh/?id=20924740030
- sam_lowry_ 1y agoIs this related to https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-... ?
- cyberax 1y agoHow do you even _get_ it to show as revoked? I tried FF, Chrome, Safari, curl, wget.
- deleted 1y ago[deleted]
- 8cvor6j844qw_d6 1y agoGiven 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 https://gs.statcounter.com/browser-market-share
- suriya-ganesh 1y agoSo far, I've tried this in, chrome, firefox, safari, arc and comet. loads in all of them
- deleted 1y ago[deleted]
- oofbey 1y agoSounds like letsencrypt is being quite premature by turning off OCSP. https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life 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.
- jsiepkes 1y agoAs far as I know OCSP isn't enabled by default in any browser.
- chrismorgan 1y agoIt’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-comprehensive-certificate-revocation-checking-in-firefox/ 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/init/StaticPrefList.yaml#16999-17009 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/init/StaticPrefList.yaml#17013-17019 https://searchfox.org/firefox-main/source/modules/libpref/in...
- wongogue 1y agoIt’s a negative on Firefox 142, Chrome 140 and iOS Safari.
- zephyreon 1y agoSeems 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?
- deleted 1y ago[deleted]
- deleted 1y ago[deleted]
- Dylan16807 1y agoIf you don't do a job at all, have you done a bad job?
- redleader55 1y agoChecking 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.
- zephyreon 1y agoSo 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?
- monkaiju 1y agoHas anyone gotten it to show as revoked?
- userbinator 1y agoDon't forget revocation checking = more centralised control, although they seem to have gone with very-short-lived certificates instead.
- Dylan16807 1y ago> 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?
- perching_aix 1y agoIt'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.
- mholt 1y agoRevocation 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.
- jofla_net 1y agoSometime 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.
- synotna 1y agoOCSP is deprecated for CRLs Let's encrypt already EOLd OCSP
- johnecheck 1y agoI'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?
- kingstnap 1y agoRevocation 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.
- snailmailman 1y agois this specific page supposed to show as revoked? its not showing as revoked for me in firefox, but https://revoked.badssl.com/ https://revoked.badssl.com/ does so i know my browser is doing revocation checking. I'm curious whats happening here.
- zephyreon 1y ago> https://revoked.badssl.com https://revoked.badssl.com This loads fine in Safari on iOS 26 lol.
- monkaiju 1y agoAlso in Fennec 129...
- deleted 1y ago[deleted]
- tsimionescu 1y agorevoked.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...
- lucumo 1y agoInterestingly 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.
- lucumo 1y agoTo clarify, https://revoked.badssl.com/ https://revoked.badssl.com/ is the one being blocked. https://revoked-isrgrootx1.letsencrypt.org/ https://revoked-isrgrootx1.letsencrypt.org/ shows just fine.
- prirai 1y agoThe certificate expiry is Dec 2025 so it's valid.
- bawolff 1y agoThat'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.
- usr1106 1y agoDetails: https://www.ssllabs.com/ssltest/analyze.html?d=revoked-isrgrootx1.letsencrypt.org 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.
- sugarpimpdorsey 1y ago> 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).
- usr1106 1y agoAs part of their details they mention browser behavior. And that part is incorrect.
- hannob 1y agoFor 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.
- yegle 1y ago[citation needed]
- NoahZuniga 1y agoI 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.
- jschanck 1y agoFirefox / 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/XpmIf5DhfTg/m/Wi5T-gvEAwAJ https://groups.google.com/a/chromium.org/g/ct-policy/c/XpmIf.... [2] https://github.com/C2SP/C2SP/blob/main/static-ct-api.md https://github.com/C2SP/C2SP/blob/main/static-ct-api.md
- thayne 1y agoSeveral 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.
- mholt 1y agoContext: 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 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 https://gist.github.com/sleevi/5efe9ef98961ecfb4da8 -- most servers have such a bad implementation of OCSP stapling that it makes sites less reliable, not more.
- strcat 1y agoOther web servers have a reliable implementation of OCSP stapling via their support for loading the OCSP response from an external file. It isn't as convenient as having it built-in but it works well. GrapheneOS used https://github.com/tomwassenberg/certbot-ocsp-fetcher 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 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.
- selinkocalar 1y agoCertificate 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…
- geldedus 1y agoUnclear message on the page. I still don't know if the certificate is revoked or not.
- inahga 1y agoFor those (i.e. me) who were concerned that the cert wasn't actually revoked, it is. https://crt.sh/?id=20924740030 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