A fairy long title, but it describes exactly what this post is about. Once again a post about a Microsoft product and the way it works (or rather doesn't work) with your average Internet standard.
This week I was busy with RADIUS, 802.1x, PKI and the protection of websites with SSL encryption. For the implementation of 802.1x, I needed a PKI environment, so I used the Microsoft Certificate Services for that purpose. Along the way, I needed an SSL certificate for an internal website, but this particular website needed to work properly based on different FQDN's and or IP addresses without throwing warining or errors regarding the SSL connection.
The way to do this is to add Subject Alternative Names (SAN) to the certificate. This enables you to access the website in different ways, e.g.;
- Access a webmail host from the internet based on its official FQDN (https://webmail.somedomain.com)
- Access the same webmail host from the inside of the corporate lan based on its internal name (https://webmail.acme.local)
- And access the host from legacy DNS-unaware software on its IP address (https://192.168.1.254)
To do this you need to create a certificate with the official FQDN as the Common Name (CN), and add the alternate name(s) and IP address(es) as Subject Alternative Names. A certificate example is displayed below.
Certificate details with several SAN'sWhen you connect with a browser to the host you should receive no warnings whatsoever regarding the SSL connection no matter which CN or SAN you use in the address bar of the browser. This works properly with the following browsers:
- Mozilla FireFox (and probably every other Mozilla based browser)
- Google Chrome
- Apple Safari
Firefox connect with SSL to an IP address without a problem
Google Chrome connect with SSL to an IP address without a problem
Apple Safari connect with SSL to an IP address without a problemMicrosoft Internet Explorer works as long as you don't connect based on the IP address listed in the SAN field. The DNS entries in the SAN work fine, but the IP Address entries result in a (familiar) warning.
Something that (according to several sources) shouldn't happen. The RFC3280 describes the valid contents of the Subject Alternative Name field:
The subject alternative names extension allows additional identities to be bound to the subject of the certificate. Defined options include an Internet electronic mail address, a DNS name, an IP address, and a uniform resource identifier (URI).
and
When the subjectAltName extension contains a iPAddress, the address MUST be stored in the octet string in "network byte order," as specified in RFC 791 [RFC 791]. The least significant bit (LSB) of each octet is the LSB of the corresponding byte in the network address. For IP Version 4, as specified in RFC 791, the octet string MUST contain exactly four octets. For IP Version 6, as specified in RFC 1883, the octet string MUST contain exactly sixteen octets [RFC 1883].
Also, VeriSign, a leading Certificate Authority has the following on their website:
SAN Certificates are often used for Unified Communications (UC) to secure Microsoft Exchange 2007 Server, Office Communications Server 2007 or Mobile Device Manager as well as server names, intranet and .local names. For example, you can secure all these domains with a single SAN Certificate:
www.bizybank.com
www.exchange.bizybank.com
www.bizybank.net
www.new-bizybank.net
SAN may also be used for:
- Servers within your intranet by name (example "server.local" or "faxtool")
- Hostnames (example - mailserver)
- Private IP addresses as published in RFC 1918
The IP addresses mentioned in RFC 1918 are the private IP ranges (10.0.0.0/8, 192.168.0.0/16, etc.), and the IP address used in the SAN (192.168.1.254) is part of those ranges.
So Microsoft screws us once again with their implementation of the Internet standards....