1955023 - SEC_ERROR_REVOKED_CERTIFICATE on start.emailopen.com with security.pki.crlite_mode=2

Status: RESOLVED FIXED

(Core :: Security: PSM, defect, P1)

Description

[Matthew Turnbull [Bluefang]]

As best as I can tell, the cert for this site is valid and has not been revoked. This seems to have happened more recently than Bug 1933594 / Bug 1950218 changing the default, so perhaps a functional regression or a false positive in the dataset? Setting security.pki.crlite_mode to 1 or 3 allows the page to load.

https://crt.sh/?id=17201691847
https://certificate.revocationcheck.com/start.emailopen.com
https://www.ssllabs.com/ssltest/analyze.html?d=start.emailopen.com&latest

Steps to reproduce:

1. Create a new Profile
2. Allow CRLite data to download (not sure how to trigger this other than waiting)
3. Visit https://start.emailopen.com/ or https://www.emailopen.com/

Actual results:

Site fails to load with SEC_ERROR_REVOKED_CERTIFICATE

Expected results:

Site loads without error.

Comment 1

[John Schanck [:jschanck]]

Thank you very much for this report!

I've identified the root cause and submitted a PR to the crlite repository: https://github.com/mozilla/crlite/pull/346.

This will be fixed without changes to Firefox, but I'll keep this bug open for tracking. I'm only marking 138 as affected, since 137 is already in late beta and security.pki.crlite_mode=2 is only the default in nightly and early beta builds. This will be resolved before 138 goes to beta.

For what it's worth, I checked several hundred certificates from the same issuer and found one other false positive:
https://crt.sh/?id=17173263186

Comment 2

[John Schanck [:jschanck]]

Update: crlite #346 has been deployed to our production CRLite instance. I've confirmed that the start.emailopen.com certificate is now stored correctly in the database, as are approximately 7800 other certificates. We expect that < 1% of these certificates show as false positives in the published CRLite artifacts. All of the affected entries discovered so far were issued by one of four CAs (1, 2, 3, 4).

The mitigation from crlite #346 can only be applied after we observe a new certificate from an affected CA in a CT log, so we may discover other affected issuers in the coming days.

CRLite artifacts persist in remote settings for up to 45 days after being published. The affected artifacts are not scheduled to be removed until April 30, but I will manually clear the collection sometime before then (likely in the next week) and I will mark this issue as resolved.

Comment 3

[John Schanck [:jschanck]]

New CRLite artifacts have been published.