SEC_ERROR_REVOKED_CERTIFICATE on hetzner.com due to security.pki.crlite_mode=2 (Nightly default)
Categories
(Core :: Security: PSM, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr78 | --- | unaffected |
| firefox84 | --- | disabled |
| firefox85 | --- | disabled |
| firefox86 | --- | fixed |
People
(Reporter: bugzilla, Assigned: keeler)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: nightly-community, regression, Whiteboard: [psm-assigned])
Attachments
(1 file)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:86.0) Gecko/20100101 Firefox/86.0
Steps to reproduce:
Visit https://www.hetzner.com in Firefox Nightly 86.0a1 (2020-12-18) (64-bit) on macOS 10.15.7
Actual results:
I get an error that the certificate was revoked:
Secure Connection Failed
An error occurred during a connection to www.hetzner.com. Peer’s Certificate has been revoked.
Error code: SEC_ERROR_REVOKED_CERTIFICATE
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.
The connection is fine in Chrome (stable) on the same laptop. Someone else in #nightly also confirms that they see the same error, so it's not just my connection, and that it's fine in Firefox release channel.
Expected results:
The site should work, I think.
Also, maybe it should get me some details on what the cert is? I don't see any option for it to tell me what it saw or why it decided it was revoked.
|
Reporter | |
Updated•4 years ago
|
|
|
Reporter | |
Comment 1•4 years ago
|
||
Let me know if you want a pcap or something.
|
||
Comment 2•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
||
Updated•4 years ago
|
|
||
Comment 4•4 years ago
|
||
I can't reproduce this on OSX - about:support gives me version 86.0a1 build 20201220093524
If you can get me a pcap with the certificate chain, that would be great, yes please.
|
|
Reporter | |
Comment 5•4 years ago
|
||
I'm still getting this on 20201220093524. I've uploaded a pcap to https://kerberos.club/tmp/hetzner-revoked.pcap. Looks like this is the chain, assuming I'm reading the pcap right:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
08:c1:ad:80:c1:f5:03:a6:0a:3a:42:22:cd:79:4c:b8
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=Thawte EV RSA CA 2018
Validity
Not Before: Jul 9 00:00:00 2020 GMT
Not After : Aug 22 12:00:00 2021 GMT
Subject: businessCategory=Private Organization/jurisdictionCountryName=DE/jurisdictionStateOrProvinceName=Bayern/jurisdictionLocalityName=Ansbach/serialNumber=HRB 6089, C=DE, ST=Bayern, L=Gunzenhausen, O=Hetzner Online GmbH, CN=www.hetzner.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ab:e5:5e:df:b4:4d:c1:bf:62:f6:7a:dd:3b:37:
17:04:0e:20:29:fe:32:71:ad:6f:7d:35:9c:dd:76:
bc:c2:05:9b:a7:6a:b0:71:17:0e:86:dc:ad:65:fe:
14:0d:09:4a:54:f2:5a:8e:7d:94:07:82:2b:c1:1c:
f6:dd:51:05:17:72:43:0b:c9:12:b2:c6:49:33:d6:
8a:34:4d:e6:f5:1f:6b:2f:1c:08:14:c1:b2:12:15:
a7:7e:34:cb:9c:03:61:b2:af:11:a0:a6:75:21:f9:
62:34:a3:6b:3a:a6:e0:18:c6:21:d1:e8:89:c3:b2:
17:dc:33:2c:1a:2b:b7:68:c6:f3:f8:3a:a2:19:75:
40:57:39:70:41:df:32:f1:45:e3:8a:81:24:e5:8a:
aa:61:80:08:9d:a1:38:3f:cc:88:4d:85:97:5e:db:
09:a1:85:78:bd:63:b4:24:2e:a1:de:d3:45:73:30:
57:3b:e5:10:74:81:c1:ea:f3:df:bb:d4:ed:a7:f5:
7a:c2:d4:27:46:de:ee:57:b1:c4:87:94:20:fc:79:
10:c7:da:4f:69:4c:af:10:44:83:89:9c:0c:51:f8:
fd:ca:0e:68:33:68:00:d5:95:50:84:a6:d3:0c:fb:
27:01:0e:79:68:06:28:72:b4:9c:1a:75:c0:41:64:
71:0f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:E7:01:FC:0C:16:18:CA:7D:B2:8C:EC:87:27:A3:6F:61:81:3B:84:39
X509v3 Subject Key Identifier:
1E:97:FB:19:06:44:B4:28:A3:F5:08:06:11:A4:90:C9:95:B8:16:3A
X509v3 Subject Alternative Name:
DNS:hetzner.com, DNS:www.hetzner.com
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://cdp.thawte.com/ThawteEVRSACA2018.crl
X509v3 Certificate Policies:
Policy: 2.16.840.1.114412.2.1
CPS: https://www.digicert.com/CPS
Policy: 2.23.140.1.1
Authority Information Access:
OCSP - URI:http://status.thawte.com
CA Issuers - URI:http://cacerts.thawte.com/ThawteEVRSACA2018.crt
X509v3 Basic Constraints: critical
CA:FALSE
1.3.6.1.4.1.11129.2.4.2:
......u..\./.w0".T..0.V..M..3.../ ..N.d....s2........F0D. L....D_.\..Q..[j.2.Je.t..n....... ;U....<;,.U.:,p..x........'1...Q.v.\.C....ED.^..V..7...G..s..^........s2........G0E. F=
|
||
Comment 8•4 years ago
|
||
Bug 1683547 has some more interesting details. It seems to be caused by CRLite, which is only in "enforce" mode in Nightly. Changing security.pki.crlite_mode in about:config to 0 or 1 makes the site work again.
|
|
||
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
||
Comment 10•4 years ago
|
||
Interestingly this happens not on Nightly for Android.
|
||
Comment 11•4 years ago
|
||
(In reply to a.nolting from comment #10)
Interestingly this happens not on Nightly for Android.
I don't think CRLite is enabled on Android: https://bugzilla.mozilla.org/show_bug.cgi?id=1677157
I find it odd though, that the leaf certificate is only signed by a single log (https://crt.sh/?id=3073817518 and https://transparencyreport.google.com/https/certificates/hgDZTYv6YW%2FwX7jB1%2B5NptsLGAJTHWOwWG%2BbNp7MhMU%3D). It shouldn't be against the CT policy (AFAIK) and I'm not sure the "crlite fetch logic" check if the certificate is "CT Qualified", if it does, maybe that's the issue.
|
|
||
Comment 12•4 years ago
|
||
(In reply to Kristian Klausen from comment #11)
(In reply to a.nolting from comment #10)
Interestingly this happens not on Nightly for Android.
I don't think CRLite is enabled on Android: https://bugzilla.mozilla.org/show_bug.cgi?id=1677157
I find it odd though, that the leaf certificate is only signed by a single log (https://crt.sh/?id=3073817518 and https://transparencyreport.google.com/https/certificates/hgDZTYv6YW%2FwX7jB1%2B5NptsLGAJTHWOwWG%2BbNp7MhMU%3D). It shouldn't be against the CT policy (AFAIK) and I'm not sure the "crlite fetch logic" check if the certificate is "CT Qualified", if it does, maybe that's the issue.
CRLite is set to enforced mode (2) on Nightly for Android.
|
||
Comment 13•4 years ago
|
||
Hello,
I don't know if I should open a new bug report for this, but the same behaviour seems to be happening with https://fontawesome.com/ using Nightly 86.0a1 build 20210107040715 (64-bit) on Linux.
As with the original report, the issue appears to be with default security.pki.crlite_mode = 2 in Nightly. Changing the value to 1 or 0 results in the webpage loading correctly, and it loads fine in stable FF (which has default security.pki.crlite_mode = 1).
|
|
||
Comment 14•4 years ago
|
||
Hi all,
the update to Version 86.0, Build-ID 20210107213748 works for me.
I would like to say Thank you to all of you for your great support.
Best Alex
|
|
||
Updated•4 years ago
|
|
||
Comment 16•4 years ago
|
||
I am also encountering the SEC_ERROR_REVOKED_CERTIFICATE with [ https://www.straitstimes.com/ ]. Setting security.pki.crlite_mode = 1 will let me see the site.
My Build ID: 20210108094818
My User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0
|
Assignee | |
Comment 17•4 years ago
|
||
This is a backout of b635c277c9f4 (bug 1675138).
It seems that the CRLite certificate transparency ingestion machinery is
missing certificates it should know about, which means that false positives are
possible, which means that users are seeing revoked certificates where they
shouldn't. This patch sets CRLite back to telemetry-only mode while the
infrastructure gets fixed.
|
||
Updated•4 years ago
|
|
|
Assignee | |
Updated•4 years ago
|
|
||
Comment 18•4 years ago
|
||
|
||
Comment 19•4 years ago
|
||
| bugherder | ||
|
||
Updated•4 years ago
|
|
|
Assignee | |
Comment 21•3 years ago
•
|
||
For posterity, our analysis of this bug was as follows:
Firefox was unexpectedly treating some sites as revoked when we enabled CRLite (turning CRLite off fixed the issue). The certificates in question were not revoked according to OCSP or CRL, and so they should not have been treated as revoked (i.e. CRLite evidently had false positives). The certificates were issued by issuers that are enrolled in CRLite, and the certificates had been disclosed to CT logs that CRLite ingests. Furthermore, the certificates were not "too new" to be covered by CRLite. Thus, CRLite should have been able to handle these certificates correctly.
Due to its construction, the only way CRLite can have false positives is if its set of not revoked certificates is missing otherwise valid and applicable certificates (or if a cosmic ray or bad hardware flipped some bits). Given that these certificates should have been present in the set of not revoked certificates (see previous paragraph), we concluded that there must be a bug whereby CRLite can either drop or never even process information about certificates that it should know about in order for it to maintain the property that CRLite not have false positives.
After some investigation, we have not determined how this bug occurs. We turned CRLite off again in the meantime.
Description
•