Windows Server 2003 Service Pack 1 AND IIS 6.0: Host Headers and SSL
It was my desire to write a blog at 35,000 feet once I determined that internet was available on my flight from Seattle to Copenhagen last Saturday. It didn’t work out as it seems that we had too much “demand” for the internet and my connection was absolutely horrible and sleep was just way too attractive.
Though, today, Thursday makes me happy to report that my connection seems to be working and I thought I would give it a ‘dog gone try (US southern lingo for — my very best attempt!)
Today’s topic came from what seem to be a very popular topic yesterday during a presentation I did at IT Forum — Host Header & SSL support in Service Pack 1. The unfortunate requirement in previous versions of IIS up to and including IIS 6.0 RTM is that for each site requiring a unique host header binding you must use a unique IP address. If you did not, you would find a few mysterious and random warnings in your event viewer that look like the following:
Event Id: 115
Description: The service could not bind instance X.
As the article 186810 points out, the X corresponds to the Site Id that is represented in the metabase. For a quick search of Site Id’s, open the IIS Manager and click the Web Sites folder and you will see the Site Name and the Id to the right. This error indicates that you have attempted to use SSL on this website where a host header value exists.
Wildcard Certificates
To my point of this blog, IIS 6.0 as of Service Pack 1 supports the ability to now use Host Headers and SSL. The single requirement though is that you must use a “special” kind of certificate from your certificate authority. The type of certificate that you need to purchase is called a “Wildcard Certificate” and is available for purchase from several Certificate Authorities. Let me define “Wildcard Certificate” first prior to telling you why you should care -
Wildcard Certificate: This type of certificate is specially created by not requiring a specific sub-hostname but instead is replaced with a “*”. In other words, instead of you having to purchase a certificate with the common name of “hr.contoso.com” you can instead purchase a certificate that is good for “*.contoso.com”.
Tell me why I care…First off, how many certificates do you possibly manage if you have this scenario:
a). www.contoso.com
b). hr.contoso.com
c). purchasing.contoso.com
If you want a seemless SSL connection with not client popups, then you should probably make sure that you have 4 certified certificates. If you do that math, just using Verisign, that would cost you ~1200 US dollars. If possible, though, wouldn’t it be really nice if you could purchase a single certificate for a slightly larger price and use that across all your sites listed above? You can — it’s called a wildcard certificate.
Testing Host Headers and SSL
The most effective method of trying out this environment is to use a tool that Microsoft released as part of the IIS 6.0 Resource Kit Tools called “SelfSSL.” The first step is to download this tool and then locate the SelfSSL executable (%programfiles%\iis resources\selfssl).
For purpose of demonstration, I suggest that you keep your environment as simple as possible by doing the following:
1). Create a New Website called SSL Test 1 using IIS Manager or IIsWeb.vbs
2). Open a CMD prompt, change to the \inetpub\adminscripts directory (on most installs, this is C:\)
3). For simplistic purposes, you will need to locate your Site Id. Since I haven’t taken the time to put pictures in, let me tell you quickly how to find the newly created site’s Id:
cscript adsutil.vbs enum w3svc
4) Open a CMD prompt, change to the “%programfiles%\iis resources\selfssl” directory
5). Now issue the following command exactly as typed:
selfssl /s:{SiteId} /N:cn=“*.contoso.com” /q
This successfully created a self-signed certificate that has the common name of “*.contoso.com” and successfully assigned that the site id you provided it.
Unfortunately, there is one required step beyond this and it cannot be done using the IIS Manager. The reason this feature didn’t work in Windows Server 2003 RTM is a slight bug in the User Interface whereby anytime you modified the ServerBindings or SecureBindings metabase property the value would be overriden no matter if you wanted or desired it to. Thus, we fixed this problem in the service pack 1 update to Windows Server 2003.
Thus, you can now use the command-line to input a SecureBindings setting that will stay permanately unless you choose to change it. There is no UI support that allows you to do this graphically.
6). Open a CMD prompt, change to the \inetpub\adminscripts directory (on most installs, this is C:\)
7). The last step is to type the following:
cscript adsutil.vbs set w3svc/{site id}/SecureBindings “:443:*.contoso.com” <press Enter>
Banda bing, bada boom, wam, bam, thank you ma’am — You now have a working Host Header based site with a Secure Binding. Thus, your customers can now request anything such as hr, purchasing, or even retail.purchasing as the common name and the certificate will not inadvertantly throw an error.
For more documentation on this feature, I suggest you visit the following:
IIS Webcast Series:
Using Host Headers with SSL-enabled websites in IIS 6.0
Nov. 29th, 2006
IIS 6.0 Product Documentation:
Enjoy and let me know if you have problems!
~Chris
P.S.: If anyone cares, at time of actual publishing the altitude was 36,000 feet