Multiple SSL Sites on a Single IIS Server Using Host Headers

Wildcard SSL certificates can allow you to publish multiple IIS web sites--all using SSL on port 443--that are accessible by host headers. That is, if you're running on IIS 6 or above.


So you read about these things, wildcard certificates, but mostly you read about how to buy them. It is possible (and easy) to create one for yourself, however, so long as you don't mind it not being trusted by folks' browsers. There are some really good uses for these, not least in a test environment in which you don't care about the trust. 
Production environments need them, too, sometimes, such as when you're using a network appliance like a Netscaler or F5 load balancer. Those devices allow you to point multiple URLs (cnames, really) to a single (or multiple) server(s). Very handy.
In our case, we have several web sites that we'd like to secure using SSL. Problem is: they're all on a single server. There are several options for dealing with such a case: assign multiple IP addresses to the server, use different SSL ports for each IIS site, or (definitely the coolest option) use a wildcard certificate on the server to allow IIS to decipher the http host header. This option, by the way, is a new feature with IIS 6, so if there's anyone out there still using IIS v5, this is another reason to upgrade.



Background
A little background on the problem might be in order: a SSL certificate is used to encrypt the http data. Normally, in setting up a IIS web site, we differentiate that site from all the others by assigning unique host headers to each site. IIS can use those host headers to determine to which site to route any given http request.
When the site is using ssl, however, the host header is encrypted, which introduces something of a chicken-and-egg thing: since the host header (along with all the rest of the data) is encrypted, IIS can't use that to determine which site to send the request to. And, since a SSL certificate is site-specific, IIS can't use a certificate to decrypt the data until it knows which site the request belongs to.
Thus, it widely is reported that it isn't possible to have multiple SSL sites on a single server, all sharing the same port. Enter wildcard SSL certificates and secure server bindings.
The wildcard certificate allows IIS to use the same certificate for all of the sites on a particular port. That takes away the requirement that IIS know which site's certificate to use in decrypting the data.
Secure server bindings help IIS in securing the wildcard certificate, a requirement for setting this up.
Note that a similar solution is available to apache. You can read about it here.
Thus, it is very possible to have multiple SSL sites on a single server, all sharing the same port.


Configure your sites to use host headers
Host headers are the backbone of this. Open the properties window for each site in IIS and click the advanced button. There, you can add the appropriate host header on port 80.


Creating a self-signed wildcard SSL certificate
The next step in this process is to make sure that all of the relevant sites have the same SSL port assigned to them.
In IIS, go to each site's properties and enter the appropriate port number (the same one for each site) in the SSL Port field. 443 is the default SSL port.
Note that once you do this, all but one of the affected sites will stop. That is because, at this point, IIS isn't configured to allow multiple sites to share the same SSL port. 
That's OK; we'll take care of that in a moment. 


Now, to generate the certificate: using SelfSSL, generate the certificate for one existing IIS site.
SelfSSL is a tool that's a part of the Microsoft IIS Resource kit.
If you haven't downloaded and installed it, you'll need to do that first.


Here's the syntax:

selfssl /n:cn=*.server.edu /s:1 /P:443 /v:3650

Where *.server.edu would be your own URL. So if you had these sites: 

mysite.sharepoint.com 

portal.sharepoint.com 

auth.sharepoint.com 

you'd use this code:

selfssl /n:cn=*.sharepoint.com /s:1 /P:443 /v:3650

It's the * that makes it a wildcard certificate. 

The /s:1 is the site identification. There are a variety of ways to view a site's identifier, but the easiest simply is to open the IIS manager and click on the "web sites" tree on the left. The right-hand pane will show the description and identifier. The default site has an identifier of 1; the other sites have very long identifiers. 

/P: is the SSL port you're using, and /V: is the number of days for which this cert is valid. Why would you want it to expire, anyway? 

 Now you've generated a wildcard certificate. 

Assign the Certificate to your sites 

 The easiest way to assign a certificate to a site, having already created it, is to view the site properties in IIS Manager. 

Click on Directory Security, and then on the Server Certificate button. This will start the wonderful wizard of IIS. You already have created a certificate, so when the wizard prompts you, choose "Assign an existing certificate." When you click next, you'll see a list of available certs, including the wildcard certificate you created. 

Select this certificate, click next, and make sure you assign it the same port that was assigned to the first site.  

That's it: once the wizard has finished its magic, you've assigned the cert to your site. Repeat this for all of the sites you want to secure on this port with SSL. 

Configure Secure Server Bindings 

 This is the final step. It involves running a vbs script to set up secure bindings, which allows IIS to use host headers with SSL and secure the new wildcard certificate you created and installed. 

 The syntax is like this:

cscript adsutil.vbs set /w3svc/844934796/SecureBindings ":443:mysite.sharepoint.com"

The adsutil.vbs script, at least on my systems, is at C:\Inetpub\AdminScripts. You'll need to run the script command from that location. 

 The syntax breaks down like this: 

844934796 is the site ID. Substitute your own site identifier there. 

443, again, is the port 

mysite.sharepoint.com is the host header for the site. 

Make sure that you have this host header configured in the site properties in IIS, as well. 

Run this script for each of your IIS sites. That should be all you need to do. 

Start up the stopped sites after you've run cscript, and you should be good to go. 

 Microsoft has a few documents that run through this, but they don't really put the pieces together for you. Here they are: Configure SSL Host Headers (IIS 6.0) Configuring Server Bindings for SSL Host Headers (IIS 6.0) Obtaining and Installing a Wildcard Server Certificate 

 By the way: if you've done a lot of testing, and you've generated a bunch of certificates you're no longer using, you can delete them. Run mmc.exe and add the certificates snap-in. You'll want to choose the "local computer" version. Using that, you can manage all of your local certificates, including deleting the ones you no longer need.