mozilla::pkix: IsValidDNSID should allow the TrustDomain more control over how many labels a wildcard DNSID must have
Categories
(NSS :: Libraries, enhancement)
Tracking
(Not tracked)
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.
|
||
Updated•4 years ago
|
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.
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.
|
||
Comment 4•4 years ago
|
||
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.
Description
•