From $url: 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 192.168.3.48. The upstream bug _may_ be: https://bugzilla.mozilla.org/show_bug.cgi?id=578697
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.
