I was reading the blog post here: The difficulty of making sure your website is broken - Let's Encrypt, and I noticed the "revoked" link for X1 was showing valid, with no security errors. I checked the other 3 revoked links, and they're also showing valid.
Let's Encrypt now only uses CRL for revoked reporting. It no longer uses OCSP.
Looks like your browser is not checking CRL
That cert is revoked. You can see that here: SSL Server Test: revoked.x1.test-certs.letsencrypt.org (Powered by Qualys SSL Labs)
Or here when crt.sh works: https://crt.sh/?id=26717646053
That isn't at all unexpected:
Tried two different browsers (Brave and Edge) and another device (Brave and Safari). None show an error.
Have you tried Firefox? it does show an error when visiting the test pages.
Here is why they don't show as revoked:
To avoid a big load on the internet, Chromium-based browsers (Edge, Brave and Chrome) and also Apple based browsers (Safari) will not check online revocation.
Instead, they use something that is called CRLSet, which means that Google/Apple is "composing" a big CRL out of a lot of CRLs, based on browsing data.
In this way, if your site is important (has many visitors) , your revoked certificate will end up in CRLSet, but if your site is less visited, it will ignore that.
CRLSet is then sent with each browser update. It kinda works like HSTS preload.
This is to ensure the internet pipes are not clogged by fat CRLs that make blockages in the pipes.
In CRLSets I know also that EV certificates are given a "green light go" through the CRLSet system - because these certificates are more important. Of the remaning space in the CRLSet, larger sites with DV or OV certificates that are revoked, are put there, and "larger site" is based on browser data, so a site with more visiitors get higher up in the CRL queue to get their revoked cert onboard the "CRL boat".
And once the "CRL boat" is full, it will sail and no more less important revoked certificates will get to sail. Meaning thats why some revoked certs don't show up as revoked.
Its important that once a cert expires, its removed from CRLSet, freeing up space for new certificates, meaning that with shorter lifetimes (down to 45 days), the CRLSet will have more space for revoked certificates.
Even if the revoked test site from letsencrypt is visited pretty often, Google and Apple may have put it on a "CRLSet ignore list" to avoid that those revoked certificates take up space in the "CRL Boat" that can be used for more important site, like a bank site that needs to revoke their cert.
In this way, the CRLs only needs to be requested once by Google, Firefox, Microsoft, Apple and other browser vendors. So in the future, it might even be that the standard will be changed so the CRL distribution point will be CLOSED and only those with a special API key will get access.
Meaning Lets Encrypt could run their CRL Distribution Server from a ESP if they want.
Firefox uses another system, called CRLIte, which uses a bloom filter to compress all revoked certificates to a small local file which uses a hash function to "set" bits. This results in a much smaller CRLite file, that actually includes ALL revoked certificates, however bloom fitlers have some false positives. (which Firefox have solved by "excluding" these false positives in a second bloom filter by using CT logs).
For more information on Firefox's CRLite system, see CRLite: Fast, private, and comprehensive certificate revocation checking in Firefox - Mozilla Hacks - the Web developer blog
Interesting. Appreciate the insights!