Even though Chrome, IE and Firefox support certificates with a Subject Alternative Name (subjectAltName) extension, it appears that only Firefox uses the “iPAddress” extension correctly for verifying URLs with IP addresses. Chrome and IE both return warnings about invalid domain names, if the IP address of the URL is in the certificate as an iPAddress SAN extension.

If the IP address from the URL is also in the certificate as a dNSName then Chrome and IE stop with their warnings.

If the IP address from the URL is only in the certificate as a dNSName then Chrome and IE stop with their warnings but Firefox does warn about an untrusted certificate. Ironically for the user, the error message is “The certificate is only valid for the following names:” followed by the list of entries (including both dNSName and iPAddress fields). A user could hardly be blamed for being confused if they compared the name in the browser URL with the IP address name and wondered why they were getting a warning.

So, my recommendation, certainly for usability purposes, is to include any IP addresses in the SAN extension as both “iPAddress” and “dNSName” values. This should allow Firefox, IE and Chrome to operate successfully. Of course, the neater option is to use DNS names for your servers…

To me, it is pretty clear from RFC 5280 section 4.2.1.6 what the definitively correct interpretation is. Obviously, entering an IP address in the URL means you are connecting to that IP address and verifying it as an IP address could be considered correct. Interpreting an IP address within the URL as a dNSName is questionable. The dNSName field is defined within RFC 5280 as

When the subjectAltName extension contains a domain name system
label, the domain name MUST be stored in the dNSName (an IA5String).
The name MUST be in the “preferred name syntax”, as specified by
Section 3.5 of [RFC1034] and as modified by Section 2.1 of
[RFC1123].

My interpretation of this excludes textual representations of IP addresses from dNSName values. I guess Chrome and Internet Explorer went for the “easy” option or simply did not read and interpret the RFC correctly. #FAIL!

Note that a bug about this is filed against Chromium, but nothing seems to have been done about it yet…