RFC 2818 covers the requirements for matching CNs and subjectAltNames in
order to establish valid SSL connections. It first discusses CNs that are
for hostnames, and the rules for wildcards in this case. The next paragraph
in the RFC then discusses CNs that are IP addresses:
'In some cases, the URI is specified as an IP address rather than a
hostname. In this case, the iPAddress subjectAltName must be present
in the certificate and must exactly match the IP in the URI.'
The intention of the RFC is clearly that you should not be able to use
wildcards with IP addresses (in order to avoid the ability to perform
man-in-the-middle attacks). Unfortunately our testing showed that this
rule is not adhered to by some browsers.
We created a certificate with the CN '*.168.3.48' this meets the various
rules for wildcards in CNs, but should be treated as invalid since it is
not a hostname. We then observed the errors reported by browsers when
connecting to an https server using this certificate run on IP address
The upstream bug _may_ be:
According to the upstream bug (https://bugzilla.mozilla.org/show_bug.cgi?id=578697) this was fixed in NSS 3.12.8, which is already in tree and stable.
GLSA Vote: no.
Mozilla team is not needed here.
GLSA Vote: no -> Closing. Feel free to reopen if you disagree.