{"id":1281,"date":"2013-06-29T14:39:39","date_gmt":"2013-06-29T13:39:39","guid":{"rendered":"http:\/\/www.michaelm.info\/blog\/?p=1281"},"modified":"2013-06-29T14:39:39","modified_gmt":"2013-06-29T13:39:39","slug":"ip-addresses-in-subjectaltname-in-ssl-website-certificates-fail-for-some-browsers","status":"publish","type":"post","link":"http:\/\/www.michaelm.info\/blog\/?p=1281","title":{"rendered":"IP addresses in SubjectAltName in SSL website certificates #fail for some browsers"},"content":{"rendered":"<p>&nbsp;<\/p>\n<p>Even though Chrome, IE and Firefox support certificates with a Subject Alternative Name (subjectAltName) extension, it appears that only Firefox uses the &#8220;iPAddress&#8221; 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\u00a0iPAddress\u00a0SAN extension.<\/p>\n<p>If the IP address from the URL is also in the certificate as a\u00a0dNSName then Chrome and IE stop with their warnings.<\/p>\n<p>If the IP address from the URL is only in the certificate as a\u00a0dNSName then Chrome and IE stop with their warnings but Firefox does warn about an untrusted certificate. Ironically for the user, the error message is &#8220;The certificate is only valid for the following names:&#8221; 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.<\/p>\n<p>So, my recommendation, certainly for usability purposes, is to include any IP addresses in the SAN extension as both &#8220;iPAddress&#8221; and &#8220;dNSName&#8221; values. This should allow Firefox, IE and Chrome to operate successfully. Of course, the neater option is to use DNS names for your servers&#8230;<\/p>\n<p>To me, it is pretty clear from\u00a0<a title=\"RFC5280\" href=\"http:\/\/tools.ietf.org\/html\/rfc5280#section-4.2.1.6\" target=\"_blank\">RFC 5280\u00a0section 4.2.1.6<\/a>\u00a0what 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<\/p>\n<blockquote><p>When the subjectAltName extension contains a domain name system<br \/>\nlabel, the domain name MUST be stored in the dNSName (an IA5String).<br \/>\nThe name MUST be in the &#8220;preferred name syntax&#8221;, as specified by<br \/>\nSection 3.5 of [RFC1034] and as modified by Section 2.1 of<br \/>\n[RFC1123].<\/p><\/blockquote>\n<p>My interpretation of this excludes textual representations of IP addresses from dNSName values. I guess Chrome and Internet Explorer went for the &#8220;easy&#8221; option or simply did not read and interpret the RFC correctly. #FAIL!<\/p>\n<p>Note that a <a href=\"https:\/\/code.google.com\/p\/chromium\/issues\/detail?id=72726\" target=\"_blank\">bug about this is filed<\/a> against Chromium, but nothing seems to have been done about it yet&#8230;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>&nbsp; Even though Chrome, IE and Firefox support certificates with a Subject Alternative Name (subjectAltName) extension, it appears that only Firefox uses the &#8220;iPAddress&#8221; 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\u00a0iPAddress\u00a0SAN [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[158,160,159,161,151,157,156],"class_list":["post-1281","post","type-post","status-publish","format-standard","hentry","category-technical","tag-chrome","tag-firefox","tag-internetexplorer","tag-rfc5280","tag-ssl","tag-subjectaltname","tag-x509"],"_links":{"self":[{"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1281","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1281"}],"version-history":[{"count":2,"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1281\/revisions"}],"predecessor-version":[{"id":1283,"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1281\/revisions\/1283"}],"wp:attachment":[{"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1281"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1281"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1281"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}