Certificate exceptions for root CA certificates impossible
Categories
(Core :: Security: PSM, enhancement)
Tracking
()
People
(Reporter: finnbryant, Unassigned)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/110.0
Steps to reproduce:
My work uses a self-signed certificate as an https certificate for proxying traffic to a https server. This certificate is marked as a certificate authority (clearly a mis-configuration, but one allowed by other browsers).
Accessing this website shows a security error on Firefox that cannot be overridden with an exception.
Actual results:
Despite adding an exception for this certificate, Firefox rejects it.
If I check the checkbox "This certificate can identify websites", the error is:
MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY
If I uncheck that checkbox, the error is:
MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT
Expected results:
Provide some way to add an exception for this (admittedly) poorly specified certificate.
Note that an exception can be applied on both Webkit and Chromium based browsers, and thus my work systems dept has closed complaints and recommended switching to a browser that works. I'm aware that altering the certificate is the more correct solution, but I think this bug is worth fixing because currently Firefox is the only browser that cannot accept an exception for this kind of certificate, making the problem effectively compatibility issue for Firefox.
Also note this is a regression, I'm not sure exactly when, but sometime around December 2022 this fully broke (previously leaving the "This certificate can identify websites" checkbox unchecked would allow the certificate to work, though with that checkbox checked it would always produce the MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY error).
My suggestion would be that a certificate exception plus "This certificate can identify websites" on the same CA certificate should allow it to act as a website certificate despite being a CA certificate.
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Security: PSM' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•3 years ago
|
||
Those errors are overridable. Does adding an override work in a new profile?
|
Reporter | |
Comment 3•3 years ago
|
||
I launched a new profile in Firefox Nightly.
I went to the problem url, as expected, I got a "Did Not Connect: Potential Security Issue" screen, with "Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT".
I went to settings -> privacy & security -> View Certificates -> Servers
I hit "Add exception", entered the same url, hit "Get Certificate" and added a permanent exception.
I reloaded the url, I got the "Did Not Connect: Potential Security Issue" screen with "Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT" again.
Since this is an internal work url, I can't share it, but here's some cert details (with company-specific stuff redacted)
$ openssl x509 -in cert.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
<HEX>
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=<country>, ST=<place>, O=<Company Name>, CN=<url of the site>/emailAddress=<email@company>
Validity
Not Before: Aug 23 14:05:22 2022 GMT
Not After : Aug 23 14:05:22 2023 GMT
Subject: C=<country>, ST=<place>, O=<Company Name>, CN=<url of the site>/emailAddress=<email@company>
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (4096 bit)
Modulus:
<HEX>
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
<HEX>
X509v3 Authority Key Identifier:
<HEX>
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Alternative Name:
DNS:<url of the site>
Signature Algorithm: sha256WithRSAEncryption
<HEX>
|
|
||
Comment 4•3 years ago
|
||
(In reply to Finn Bryant from comment #3)
I launched a new profile in Firefox Nightly.
I went to the problem url, as expected, I got a "Did Not Connect: Potential Security Issue" screen, with "Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT".
I went to settings -> privacy & security -> View Certificates -> Servers
I hit "Add exception", entered the same url, hit "Get Certificate" and added a permanent exception.
Presumably you're using this UI because the in-page mechanism to add an exception doesn't work? (click "Advanced", then "Accept Risk and Continue" in the error page itself)
|
|
Reporter | |
Comment 5•3 years ago
|
||
That UI never appears at all.
In the advanced tab all I see is:
<url> uses an invalid security certificate.
The certificate is not trusted because it is self-signed.
Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT
View Certificate
And the only button is a copy of the Go Back button that appears outside the advanced UI.
|
|
Reporter | |
Comment 7•3 years ago
|
||
Does the error page mention "HSTS"?
Yes it does, once I click on the MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT error, in the raw text output:
The certificate is not trusted because it is self-signed.
HTTP Strict Transport Security: true
HTTP Public Key Pinning: false
In addition, I have now tried to create an equivalent cert and reproduce so I could attach that, but it worked correctly (the add exception button appeared, and the exception worked).
So (as I think you already assumed) I have misidentified the cause here, the CA:TRUE constraint seemingly isn't the problem, is there something specific to HSTS that might prevent exceptions?
|
|
||
Comment 8•3 years ago
|
||
Yes. Since evidently the problem persists in new profiles, my guess is you're trying to visit a domain like example.dev. The issue is that all .dev domains use HSTS, since the owner of that hierarchy (Google) has opted in to using it (https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/).
I think your options are either:
a) convince the people who run your internal site to use a certificate that is suitable as a server certificate, and sign it with a CA certificate that each employee can add to their trust store, so that connections work without error overrides (most companies do this, it's not an undue burden).
b) convince the people who run your internal site to use a different tld (a good one might be .test, since that's not actually a public tld, whereas .dev is).
c) disable the HSTS preload list by setting the about:config option network.stricttransportsecurity.preloadlist to false (note that this disables an important security feature - namely the HSTS preload list, which is how many sites opt into HSTS "out of the box", which gets around the trust-on-first-issue that HSTS has).
|
|
Reporter | |
Comment 9•3 years ago
|
||
Turning off network.stricttransportsecurity.preloadlist, and then clearing site data, did fix the issue.
The domain is .net, specifically its a company-specific subdomain of a cloud service <company>.<service>.net. We can only access via our vpn and due to limitations we needed a proxy to force vpn traffic to the cloud service to go through our vpn rather than directly (as I understand it).
I'm still unclear why having a site on the HSTS preload list would prevent adding exceptions, they seem to be unrelated steps (certificate pinning, in comparison, I can understand the conflict with - since our cert would be coming from the wrong authority the browser might have an additional layer of checks that might bypass the exception system). Given you think providing our own authority would fix it, I'm guessing the problem isn't that they're tied to a specific authority, so what other issue blocks exceptions on HSTS preloaded domains?
Note again that this issue doesn't seem to affect other browsers. It also has very poor feedback in the error dialog (apart from that 1 line mentioning hsts in the error text accessed from the advanced section of the error window, there's no other mention of the actual cause of the issue, and even that line just mentions that hsts is enabled, which afaict still doesn't directly relate to the error - why would hsts being enabled prevent certificate exceptions?).
So I'd argue for 2 possible changes - either Firefox should support exceptions applying for sites on the hsts preload list, the same as other browsers apparently do.
Or Firefox should add additional hints to the error page in this case (in the advanced box preferably, or the error details at a minimum), something like "Certificate exceptions disabled by HSTS prelist" when no exception exists, and "Certificate exception found, but disabled by HSTS prelist" when an exception has been added. Alternatively, when adding an exception in the settings, it could be rejected when the domain entered is in the HSTS preload list, since it will apparently not work and accepting it will just confuse things.
As for my workplace fixing this issue, apparently work is now started in that direction, though given I had no clue what the actual error was until now, I have no idea if they are trying to fix the wrong thing in the certificate (eg they might switch to a self signed cert with no CA, since that would have fixed the issue I incorrectly identified from the unrelated MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY error). Again, this points towards the need for better error feedback in this scenario.
Thank you for helping root cause this by the way, sorry for slowing things down with faulty assumptions.
|
|
Reporter | |
Comment 10•3 years ago
|
||
I've just realised I don't actually know why other browsers function correctly here, it's possible they would also reject exceptions for HSTS preload sites, just like Firefox, but if they don't reject in the CA_CERT_USED_AS_END_ENTITY scenario they might not require an exception.
|
|
||
Comment 11•3 years ago
|
||
(In reply to Finn Bryant from comment #9)
The domain is .net, specifically its a company-specific subdomain of a cloud service <company>.<service>.net. We can only access via our vpn and due to limitations we needed a proxy to force vpn traffic to the cloud service to go through our vpn rather than directly (as I understand it).
Sounds like your vpn isn't configured correctly, but that's not my area of expertise.
I'm still unclear why having a site on the HSTS preload list would prevent adding exceptions
The HSTS specification mandates that exceptions not be allowed to hosts that are noted as HSTS. However, if you use a well-formed certificate issued by a certificate authority that your browser trusts, it should work.
Note again that this issue doesn't seem to affect other browsers.
Other browsers presumably don't consider a CA certificate being used as a server certificate an error, so there's no need to add an error override.
Compare to what happens when you visit https://subdomain.preloaded-hsts.badssl.com/ with Chrome/Safari.
Thank you for helping root cause this by the way, sorry for slowing things down with faulty assumptions.
Happy to help!
I'll close this as "not a bug in Firefox".
Description
•