IIS, SSL and Host-Headers
 |
The article you are reading has moved! It is now available at: http://blog.tinisles.com/2008/11/iis-ssl-and-host-headers/ |
Here's a knowledge base article I use to explain why an SSL site needs its own IP address: HTTP 1.1 host headers are not supported when you use SSL. Host headers allow a web server to host several websites on the same IP address. When a browser makes a request the domain name of the website is passed in the request host header. The server uses this to check against the list of websites it is serving. When this is combined with SSL the server needs to know which website's private certificate to establish the secure session - which is impossible as the session is established before any HTTP headers are sent.
Yet the article says: "Beginning in Windows Server 2003 Service Pack 1 (SP1) and IIS 6.0, Secure Sockets Layer (SSL) host headers are supported in IIS.", and points you to the article: Configuring SSL Host Headers (IIS 6.0). So we are all covered now? Well, no. The issue of SSL session being established before the host header still exists. IIS 6 only supports host headers where all the sites being served use the same wildcard SSL certificate; e.g. *.mydomain.com.au. The server doesn't need to know the host header when establishing the session, as there is only one certificate to choose from.
Why not include the the host header when we establish SSL? That is the plan of Server Name Indication - this does mean web browsers and servers all need to be updated to support the new standard. So it will be a while before SNI is well supported on the web.
