Closed Bug 1650291 Opened 3 months ago Closed 1 month ago

mozilla::pkix: IsValidDNSID should allow the TrustDomain more control over how many labels a wildcard DNSID must have

Categories

(NSS :: Libraries, enhancement)

enhancement

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: rowanj+bugzilla, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

We have Kubernetes-deployed services reachable from several name resolution scopes, the ingress controller and pod endpoint present the same certificate with multiple DNS SAN wildcards:

*.dev8-namespace.svc.cluster.local
*.dev8-namespace
*.dev8.corporate.local

Actual results:

When Firefox connects to the ingress controller presenting this certificate at:
https://example.dev8.corporate.local/

the TLS certificate validation fails, presenting the curious error that example.dev8.corporate.local does not match *.dev8-namespace.svc.cluster.local, *.dev8-namespace, *.dev8.corporate.local
(ERROR_BAD_CERT_DOMAIN)

Note that the host does match the last SAN.

Removing the single-label wildcard *.dev8-namespace from the generated certificates resolved this issue.

Expected results:

The service's response should be displayed with no error, and a "normal" grey padlock icon.

No error is presented when connecting to these URLs with Chrome, cURL, openssl s_client, etc.

Alternatively, an error specific to the validity of the certificate might be shown if this certificate should be invalid for all hosts.

I guess this might actually be an NSS issue but I currently lack the capacity to test that directly. I suspect that encountering the single-label wildcard while iterating the SANs stores the error despite the matching entry later in the list.

I will mark this issue as a security (non-public) issue because of the connection to certificate validation; although in this case it is fail-secure, there may conceivably be related vectors to crafting malicious certificates, and I assume that can be easily un-done by the friendly triage process.

Sorry that I couldn't post the exact error - the v.78 update forced me to restart FF after I'd rolled out the new certificates and the re-opened tabs reloaded immediately as I switched to them, clobbering the error history. It did definitely indicate that the certificate didn't match the host, and not that the certificate was invalid per se.

Group: firefox-core-security → crypto-core-security
Component: Untriaged → Security: PSM
Product: Firefox → Core

The problem is most likely this entry: *.dev8-namespace. It only has two labels, whereas mozilla::pkix requires 3 [0] (generally having a wildcard with only two labels is a bad idea - e.g. having a certificate valid for *.com would be bad). That said, this is for a private PKI (presumably), so maybe it should be possible to be more flexible here.

[0] https://searchfox.org/mozilla-central/rev/91d82d7cbf05a71954dfa49d0e43824c7c973e62/security/nss/lib/mozpkix/lib/pkixnames.cpp#2030

Assignee: nobody → nobody
Group: crypto-core-security
Type: defect → enhancement
Component: Security: PSM → Libraries
Product: Core → NSS
QA Contact: jjones
Summary: single-label DNS SAN wildcard certificate validation inconsistent with other implementations → mozilla::pkix: IsValidDNSID should allow the TrustDomain more control over how many labels a wildcard DNSID must have
Version: 77 Branch → other

Affirmative, this is for private PKI, and removing the middle *.dev8-namespace SAN allowed the final *.dev8.corporate.local SAN to match as expected.

In any case I would not really expect the inclusion of any non-matching DNS SAN to prevent the operation of an otherwise valid certificate.

While this is a reasonable and sane ask, in practice this doesn't show up much (I think you're the first person reporting an incompatibility with this), with a relatively easy workaround. Plumbing configuration for these label requirements into TrustDomain is not a trivial patch. At least for now, I think this is a wontfix, sorry for the trouble.

Status: UNCONFIRMED → RESOLVED
Closed: 1 month ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.