1970872 - Revoked certificates not added to CRLite

Status: RESOLVED FIXED

(Cloud Services :: Operations: CRLite, defect, P1)

Description

[Hanno Boeck]

I noticed recently that a certificate revoked with reason keyCompromise was not added to CRLite. Given that this may bypass revocation checks for compromised certificates, it may be considered a security issue.

The cert in question:
https://crt.sh/?id=13302141633

It is at the time of writing this bug still live at:
https://posttraining.go.ke/

I had already mentioned this in Mozilla's security matrix channel, and it was confirmed that this is a bug, Frederick Braun asked me to open a bugzilla bug to track it here.

Here's a copy of the conversation in the Matrix channel:

hannob:
Hi, I wonder what the delays between a cert's revocation and it showing up in Mozilla's CRLite is.
The cert for https://posttraining.go.ke/ has been revoked 2 days ago (KeyCompromise), yet I can still access the page in Firefox.
freddy:
so, djackson tells me elsewhere that you can query crlite manually with https://github.com/mozilla/crlite/tree/main/rust-query-crlite and that it seems it's not yet included
We'll wait for someone else to take a look at why it's not covered yet and if that's a typical time frame
jschanck:
Thanks for reporting this! It looks like we have a bug that is preventing us from ingesting CRLs from this one issuer. We'll get it patched shortly.

Comment 1

[John Schanck [:jschanck]]

We pushed a patch for this to our staging environment on Friday, and the affected certificate is showing as revoked in staging:

rust-query-crlite -vv --update stage crtsh 1330214163

We just pushed the patch to prod. The next CRL aggregation run is in about 8 hours. I'll post an update here and close out this bug once I've confirmed that the affected certificates show as revoked for Firefox users.

Comment 2

[John Schanck [:jschanck]]

rust-query-crlite -vv --update prod crtsh 1330214163

shows that the https://posttraining.go.ke/ certificate is marked as revoked in 20250610-0-default.filter.delta.

The following CRLs were properly ingested for the first time:

http://crl.emsign.com/?emSignClass1CAC1.crl
http://crl.emsign.com/?emSignClass1CAG1.crl
http://crl.emsign.com/?emSignClass2CAC1.crl
http://crl.emsign.com/?emSignClass2CAG1.crl
http://crl.emsign.com/?emSignClass3CAC1.crl
http://crl.emsign.com/?emSignClass3CAG1.crl
http://crl.emsign.com/?emSignDeviceCAC1.crl
http://crl.emsign.com/?emSignDeviceCAG1.crl
http://crl.emsign.com/?emSignECCClass1CAC3.crl
http://crl.emsign.com/?emSignECCClass1CAG3.crl
http://crl.emsign.com/?emSignECCClass2CAC3.crl
http://crl.emsign.com/?emSignECCClass2CAG3.crl
http://crl.emsign.com/?emSignECCClass3CAC3.crl
http://crl.emsign.com/?emSignECCClass3CAG3.crl
http://crl.emsign.com/?emSignECCDeviceCAC3.crl
http://crl.emsign.com/?emSignECCDeviceCAG3.crl
http://crl.emsign.com/?emSignECCEVSSLCAC3.crl
http://crl.emsign.com/?emSignECCEVSSLCAG3.crl
http://crl.emsign.com/?emSignECCSSLCAC3.crl
http://crl.emsign.com/?emSignECCSSLCAG3.crl
http://crl.emsign.com/?emSignEVSSLCAC1.crl
http://crl.emsign.com/?emSignEVSSLCAG1.crl
http://crl.emsign.com/?emSignSSLCAC1.crl
http://crl.emsign.com/?emSignSSLCAG1.crl

Firefox correctly blocks access to emSign's revocation test sites, e.g.:

• https://testevg1r.emsign.com
• https://testevg3r.emsign.com
• https://testevc3r.emsign.com
• https://testevc1r.emsign.com

Comment 3

[Frederik Braun [:freddy]]

Hanno was wondering if someone could use this bug to maliciously bypass Firefox cert revocation checks. We'll discuss this in a bug bounty meeting, but would be great if you, John, or someone else could look into this from an attacker's perspective.

Comment 4

[John Schanck [:jschanck]]

A malicious CA could have used this to bypass revocation checks in Firefox. However, it is worth noting that the failure to download emSign CRLs was logged (see, for example, entry 1 in https://storage.googleapis.com/crlite-filters-prod/20250609-1/crl-audit.json). A malicious CA could perform a much stealthier attack where they serve the CRLite aggregator different CRLs than they serve to other parties. Our long term solution to all of these problems is third-party auditing of CRLite artifacts.

Comment 5

[Hanno Boeck]

Related:
https://bugzilla.mozilla.org/show_bug.cgi?id=1970703