Host Headers, Secure Site Bindings, and SSL
For IIS 7, see this page on configuring SSL host headers in IIS 7.
Host headers can be used to host multiple secure websites on one IP address. With this method the same SSL Certificate must be used for every site that is secured. If multiple SSL Certificates are used, the server usually has a problem with providing the correct SSL Certificate when an HTTPS connection is established, causing a certificate name error. However, this means that if you use host headers in combination with certificates that can cover more than one website (wildcard or UC certificates) you can secure multiple sites with SSL on only one IP.
A wildcard certificate will secure any subdomain of the domain that it was issued to. For example, a DigiCert® Wildcard Plus™ Certificate that is 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 domains, the server cannot supply an incorrect SSL Certificate.
Similarly, a single DigiCert Unified Communications Certificate can secure multiple fully-qualified domain names. And, contrary to popular belief, they 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. The certificate could then be installed to all four sites. When connecting to any 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, no error message is displayed.
Follow the instructions below to set up host headers and secure site bindings in IIS 6.
Setting Up Host Headers and Secure Site Bindings in IIS 6
- Install the SSL Certificate to the site where you will use secure bindings.
If you haven't already, configure the host headers of your site using IIS. To do this, in IIS right-click on the site you are securing and select Properties.
On the website tab, click Advanced next to the IP address field.
Click your Default identity on TCP port 80. Then click Edit and enter your domain name in the Host header field. Do this for any sites that will be sharing secure connections on the same IP.
Next, open a command line by clicking Start > Run. Type cmd and click OK.
- Type cd C:\Inetpub\AdminScripts or your system's IIS scripts directory and click enter.
Type the following command:
cscript.exe adsutil.vbs set /w3svc/site identifier/SecureBindings ":443:host header"
You can find your site identifier and host header in IIS when viewing the list of all websites from the IIS Manager. The site identifier is in the Identifier column, and the host header is in the Host header value column. The host header value is the value that is assigned to the website (e.g. digicert.com).
If you enter an invalid number as the site identifier, you will get the following error: "The path requested could not be found."
Repeat the previous step as many times as necessary to enable your SSL Certificate to be used on all of the appropriate websites. If you need to enter the command for multiple sites, we recommend using our DigiCert IIS 6 SSL Host Header Command Generator.
You may need to restart the IIS sites for the changes to take effect. You can verify the 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.
Note: If you have trouble setting up host headers in IIS or do not want to use this method, you can use different ports for each secure site (multiple secure sites can run on the same IP with different SSL Certificates if they each use a different port). However, most server administrators find this solution to be more trouble than it's worth.