Host Headers & SSL

Configuring SSL Host Headers in Microsoft IIS

Background

Host headers can be used to host multiple secure web sites on one IP address. However, the same SSL certificate must be used for every site secured. That means that host headers can be used to secure multiple sites with SSL on one IP only by using certificates that are capable of covering more than one website (Wildcards or UC certificates). If multiple SSL certificates are used, the server will usually encounter problems providing the correct SSL certificate when an HTTPS connection is established, causing a certificate name error when connecting.

A Wildcard will secure any subdomain of the domain that it was issued to. For example, a Wildcard SSL certificate issued to *.domain.com will cover something.domain.com, anything.domain.com, and whatever.domain.com. Because the *.domain.com certificate would be valid on any of these three domains, the server cannot supply the "wrong" SSL certificate.

Similarly, a Unified Communications SSL certificate can include multiple fully-qualified domain names in one certificate, and, contrary to popular belief, are not exclusively for use with Microsoft Exchange servers. In fact, UC certificates are compatible with almost all major server types. The difference between UC certificates and Wildcard certificates is that while Wildcards work on multiple websites because of the * character in the domain name, UC certificates include a Subject-Alternative-Name (SAN) field that allows the certificate to include multiple names. For example, a UC certificate can be issued to include the names www.domain.com, www.domain2.com, www.domain3.com, and mail.domain3.com. That certificate could then be installed to all four sites. When connecting to any one of those sites, a browser will check the name that it is connecting to against the list of SAN names in the certificate. As long as a valid match is found, there will not be any error displayed.

Setting up Host Headers and Secure Site Bindings in IIS 6

For IIS 7, please refer to our page discussing SSL Host Headers in IIS 7

1. Install your SSL certificate to the site to be used with secure bindings.

2. If you have not already, configure the host headers of your site using IIS.

   In IIS, right click on a site you are securing and select properties.

   From the Web Site tab, click on "Advanced..." next to the IP address field.

   Click on your Default identity on TCP port 80, then choose "Edit" to enter your domain name as the "Host header value." Do this for any sites that will be sharing secure connections on the same IP.

3. Next, you will need to open up a command line to set up your Secure Bindings.

   Go to Start > Run

4. Type "cmd" and click "OK."
5. Enter "cd C:\Inetpub\AdminScripts" to change to the IIS Scripts directory. If your system uses a different directory, go there instead.

6. Enter the following command:

   cscript.exe adsutil.vbs set /w3svc/site identifier/SecureBindings ":443:host header"

   You can find the site identifier in IIS when viewing the list of all web sites from the IIS Manager in the Identifier column. The host header is the host header value that is assigned to the web site (e.g. digicert.com).

   

   If an invalid number is entered as the site identifier, you should get an error that "The path requested could not be found."

7. Repeat the above step as many times as necessary to enable your SSL certificate to be used on the appropriate websites. If you need to enter the command for several sites, try using the DigiCert IIS 6 SSL Host Header Command Generator.

   You may need to restart the IIS sites for the changes to take effect.

8. You can verify the configuration changes by opening each site in a web browser. If the wrong page is displayed for any URL, your SSL host headers have not been configured correctly.

If you have trouble setting up host headers in IIS, you can also get around the issue by using different ports for your different secure sites (multiple secure sites can run on the same IP with different SSL certificates if they each use a different port), but most server administrators find that solution to be more trouble than it is worth.