1757758 - consider having mozilla::pkix ignore invalid entries in subjectAlternativeNames

Status: RESOLVED FIXED

(NSS :: Libraries, enhancement, P1)

Description

[Gunnar Haslinger [:Gunnar]]

Attachment: CA+Certificates.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36 Edg/98.0.1108.62

Steps to reproduce:

We are using a large amount of TLS-Server-Certificates from a private (company-internal) PKI. Those Certificates are issued with various Subject Alternative Names (SAN) containing Wildcards. All those worked fine in former Versions of Firefox (at least up to v52.9esr) but are not working in current Versions of Firefox (tested with v68esr up to current v97.0.1 and v98 beta).

Some of the SAN are not recognized as valid, Firefox shows a SSL_ERROR_BAD_CERT_DOMAIN

Other current versions of Browsers like Chrome or Edge don't show any issues with those Certificates, using Chrome or Edge works fine.

To find out why Firefox show up an SSL_ERROR_BAD_CERT_DOMAIN I set up an publicly reachable Testserver with two vHosts, one using a working certificate and one using the certificate which raises SSL_ERROR_BAD_CERT_DOMAIN. I played around with the SAN of this certificate until I finally figured out what exactly triggers this Firefox-behavior. I'm now able to describe what I think goes wrong and should be improved in the SAN-Name Handling of Firefox.

If you like to reproduce yourself you have to:

1. Import "Root-Certificate aaa-MySample-RootCA.cer" which is attached to this Issue in the File "CA+Certificates.zip"

2. add following entries to your c:\windows\system32\drivers\etc\hosts File:

5.45.107.134 firefox-certproblem-server1.local firefox-certproblem-server1 
5.45.107.134 sub.firefox-certproblem-server1 sub.firefox-certproblem-server1.local 
5.45.107.134 firefox-certproblem-server1.hitco.at sub.firefox-certproblem-server1.hitco.at

5.45.107.134 firefox-certproblem-server2.local firefox-certproblem-server2 
5.45.107.134 sub.firefox-certproblem-server2 sub.firefox-certproblem-server2.local 
5.45.107.134 firefox-certproblem-server2.hitco.at sub.firefox-certproblem-server2.hitco.at  

Actual results:

Firefox works without warning:
https://firefox-certproblem-server1/
https://5.45.107.134/

Firefox Error: SSL_ERROR_BAD_CERT_DOMAIN
https://firefox-certproblem-server1.local/
https://firefox-certproblem-server1.hitco.at
https://sub.firefox-certproblem-server1.local/
https://sub.firefox-certproblem-server1.hitco.at/

But Firefox works without warning:
https://firefox-certproblem-server2.local/
https://firefox-certproblem-server2.hitco.at
.. and all other server2 URLs

So, what's wrong with the server1 Certificate and what did I change in server2 Certificate?

1. This list of Subject Alternative Names leads to the problem in Firefox:

[ SAN_firefox-certproblem-server1.local ]
DNS.1 = firefox-certproblem-server1
DNS.2 = *.firefox-certproblem-server1
DNS.3 = firefox-certproblem-server1.local
DNS.4 = *.firefox-certproblem-server1.local
DNS.5 = firefox-certproblem-server1.hitco.at
DNS.6 = *.firefox-certproblem-server1.hitco.at
DNS.7 = localhost
IP.1  = 127.0.0.1
IP.2  = 5.45.107.134
IP.3  = 192.168.200.200
IP.4  = 0000:0000:0000:0000:0000:0000:0000:0001
IP.5  = 2a03:4000:0006:126c:0000:0000:0000:affe

2. This list of Subject Alternative Names works in Firefox:

[ SAN_firefox-certproblem-server2.local ]
DNS.1 = firefox-certproblem-server2
DNS.2 = firefox-certproblem-server2.local
DNS.3 = *.firefox-certproblem-server2.local
DNS.4 = firefox-certproblem-server2.hitco.at
DNS.5 = *.firefox-certproblem-server2.hitco.at
DNS.6 = localhost
DNS.7 = *.firefox-certproblem-server2
IP.1  = 127.0.0.1
IP.2  = 5.45.107.134
IP.3  = 192.168.200.200
IP.4  = 0000:0000:0000:0000:0000:0000:0000:0001
IP.5  = 2a03:4000:0006:126c:0000:0000:0000:affe

The problem is caused by the *.firefox-certproblem-server1 entry in the first certificate above, in line DNS.2

If you move line DNS.2 to line DNS.7 as I did in the second certificate it works.

Firefox checks if the SAN matches and does it line by line. And it STOPS and doesn't check the following SAN entries if there is a to global *.tld entry for example in DNS.2 ... then DNS.3 to DNS.7 are not checked any more. Only DNS.1 entry still works. Changing the order resolves the issue.

Expected results:

Other Browsers like Chrome or Edge check all SAN-Entries and grant those valid which are valid. If you try to access DNS.2 in Chrome or Edge you get Error NET::ERR_CERT_COMMON_NAME_INVALID but DNS.1 and DNS.3 to DNS.7 still work. Thats the difference to Firefox, Firefox stops checking DNS.3 to DNS.7 if DNS.2 is to global and therefore not a valid SAN.

Comment 1

[Gunnar Haslinger [:Gunnar]]

Just to clarify: I'm not complaining about the fact that Firefox classifies "*.firefox-certproblem-server1" as *.tld which is not a valid Wildcard-SAN-Name! I just like to point out that all other SAN Entries after the "forbidden" one are not recognized even if they are valid. And this fact should be changed / improved.

Comment 2

[Gunnar Haslinger [:Gunnar]]

Did some additional research on this:

• Bug 1196364 discusses Proper handling for wildcard certificates for all tlds ... is open for years - no idea if there is progress on this
• Bug 1489045 seems to be same issue like I'm complaining about ... only one cert was affected which was renewed to solve the issue.

I'm not able to change/renew all our certificates of those several hundreds of devices (LAN-Printers etc...) running in different LANs (would take months to do this) - currently using Chrome/Edge as a solution.

In Bug 1196364 Comment 21 those new Prefs where discussed, but it seems this was never implemented

+pref("security.pki.strict_wildcard_checks", false);
+pref("security.pki.allow_local_wildcard_domains", true);

Comment 3

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Please don't change the metadata on bugs.

Comment 4

[Robin Bankhead]

Apologies if I'm in the wrong place: I don't fully understand the discussion above but I'd like to know if this is why, between firefox-98 and -101, my self-signed wildcard certificate (with my own CA cert stored in the browser) is now throwing errors. I use it for a couple of dozen vhosts, with domain pattern

*.<subdomain>.<domain>.co.uk

Never had issues with this setup before.

Comment 5

[Gunnar Haslinger [:Gunnar]]

No, *.<subdomain>.<domain>.co.uk is not affected by this behavior.

Comment 6

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

(In reply to Robin Bankhead from comment #4)

Apologies if I'm in the wrong place: I don't fully understand the discussion above but I'd like to know if this is why, between firefox-98 and -101, my self-signed wildcard certificate (with my own CA cert stored in the browser) is now throwing errors. I use it for a couple of dozen vhosts, with domain pattern

*.<subdomain>.<domain>.co.uk

Never had issues with this setup before.

Do you have a dNSEntry in the subject alternative name extension, or are you relying solely on the subject common name? (see bug 1691122)

Comment 7

[Robin Bankhead]

Yes, that's what it is. Thanks for the steer, I should have looked at the release notes.

(Sidenote: No rationale seems to be given for that change besides "Chrome did it")

Comment 8

[Bastian Hesselbarth]

I have a very similar problem, where the way how Firefox checks an SSL-Certificate leads to Firefox rejecting the certificate with the following error:
SSL_ERROR_BAD_CERT_DOMAIN

In this case there was a bad SAN (prefixed with a colon) in the middle of valid ones. Every (valid) entry before the bad one worked, the bad entry and every valid entry afterwards did not. Other browsers (Edge, Chrome) accept the certificate.

Since the behaviour is exactly the same for SANs that are too broad as for SANs that are just broken, I'm guessing it's the same routine. That's why I'm posting here instead of a seperate bug. If this isn't correct I can file a seperate bug report and link towards it here.

Steps to reproduce:

1. Give your webserver the following Aliases:

pre-defect-host.local
defect-host.local
post-defect-host.local

2. Create an SSL-Certificate containing the following SANs and sign it with a CA that is trusted by the accessing client:

DNS.1 = pre-defect-host.local
DNS.2 = :defect-host.local
DNS.3 = post-defect-host.local

3. https://defect-host.local and https://post-defect-host.local will throw SSL_ERROR_BAD_CERT_DOMAIN

Comment 9

[Gunnar Haslinger [:Gunnar]]

Yes, I think your Issue is similar to the one I initially reported with this ticket.
Sadly nobody seems to "listen", no progress on this issue can be seen.
We already finished to change several thousand Device-Certificates to avoid this issue.

Comment 13

[Gunnar Haslinger [:Gunnar]]

Is there any chance this gets fixed some time?
Hint: Hashicorp Vault sorts SAN-List alphabetically, doesn't respect the order you requested the DNS-SAN entries.
Putting DNS-SAN Entries starting with an "*" to the alphabetically sorted top of the list.
See: https://github.com/hashicorp/vault/issues/20182

Comment 14

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Attachment: Bug 1757758 - mozpkix: add option to ignore invalid subject alternative names r?jschanck

Before this patch, mozilla::pkix would always return Result::ERROR_BAD_DER upon
encountering an invalid subject alternative name entry (most often, an IP
address encoded as ASCII in a dNSName entry).

This patch adds the option to configure mozilla::pkix to instead skip such
entries, and treat them as if they weren't present.

Comment 15

[John Schanck [:jschanck]]

https://hg.mozilla.org/projects/nss/rev/9258bb2ed2e013e6b7c1aa85c5aa03d496bbd97b

Comment 16

[John Schanck [:jschanck]]

https://hg.mozilla.org/projects/nss/rev/bae3dc8686185e3e329eebaf5e901284b2301b75 (clang format)