Limitations of aggreated CRL revocation checks

[Hanno Böck]

Hi,

I recently observed something about certificate revocation that is, in
retrospect, quite obvious, but I'm not sure if people in the WebPKI
community are widely aware of it.

As most on this list probably know, most browsers have moved away from
using revocation checks via OCSP and use aggregated CRL lists like
Mozilla's CRLite.

This may be stating the totally obvious, but: this only works for
certificates with CRLs.
We are currently seeing a mixture of practices. Some CAs have only
CRLs, some have only OCSP, and some have both.

If a certificate without a CRL is revoked, it is quite possible that a
cert gets revoked, yet is still in use,and most users will not notice
it.

CAs that currently do not have CRLs referenced in their certs may want
to consider that.

Browsers may want to consider better documenting this limitation.
(E.g., there's a FAQ for CRLite, and I think you can read it between
the lines, but adding an explicit "What about certificates without a
CRL?" may be a good idea:
https://github.com/mozilla/crlite/wiki
)

One could also consider having a requirement for CRLs in certificates
by browser root stores. (I don't have a strong opinion on whether that's
a good idea.)

--
Hanno Böck - Independent security researcher
https://itsec.hboeck.de/
https://badkeys.info/

[Bas Westerbaan]

When computing the filter, CRLite crucially requires knowledge of all certificates issued. For this it uses certificate transparency. With the full list of certificates, when computing the filter, we can check OCSP for those CAs that don't publish CRLs. I do not know if it's also done, but I'm sure John will clarify.

Best,

 Bas

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20250620101221.0b8fc555%40hboeck.de.

[Corey Bonnell]

>  This may be stating the totally obvious, but: this only works for certificates with CRLs.

There's a requirement for CA operators to disclose CRL(s) in CCADB for each CA that they operate such that all issued certificates are in the scope of the disclosed CRLs. This allows for CRL-based revocation information to be available for all certificates, regardless of whether there is a CRL Distribution Points extension in the certificate itself.

I haven't poked around the CRLite codebase to see whether it is consuming this information, but it should be possible in theory.

Thanks,

Corey

[John Schanck]

Right, Mozilla root store policy [1] requires CAs to disclose their
CRLs in CCADB. Mozilla's CRLite implementation fetches the list of
known CRLs from CCADB, via [2], every 12 hours. The implementation
does not do any OCSP fetching, and it also does not look at CRL
Distribution Points extensions in certificates (although it use to).

I'm currently improving the documentation for CRLite and I'll be sure
to note this.

Cheers,
John

[1] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#:~:text=CA%20operators%20with%20intermediate,issuing%20its%20first%20certificate%3B
[2] https://ccadb.my.salesforce-sites.com/mozilla/MozillaIntermediateCertsCSVReport

On Fri, Jun 20, 2025 at 5:08 AM 'Corey Bonnell' via
dev-secur...@mozilla.org <dev-secur...@mozilla.org>
wrote:

> To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ff770886-09da-43d1-8eca-a687685ad385n%40mozilla.org.