Host headers with SSL on IIS7
If you need to run multiple sites on the same web server, Host headers is a good choice. The sites will run on the same IP address and can use the same standard ports 80 and 443 without forcing the users to use different port numbers in URL. However, setting up Host headers does take a bit of learning and understanding how the things work.
Server side
In my case, I had an existing site site1.com running on standard ports 80 and 443. I set up another site, site2.com. I wanted site2.com to run on the same ports.
First of all, I didn’t need to touch anything on my current site site1.com. Nothing at all.
With site2.com, I needed to bind it to the same ports but with a distinct Host header. Although I could bind to port 80 via IIS management UI, for port 443 it couldn’t be done. If you are keen to know the reason, it is because of SSL certificate. With IIS UI, you could select different SSL certificates for different Host headers, but, since IIS routes http messages by their Host headers after decoding SSL, all Host headers will always use the same SSL certificate.
So, instead of trying IIS UI, you can easily bind to different Host headers with the following command-line script:
cd %windir%\system32\inetsrv
appcmd set site /site.name:site2 /+bindings.[protocol='https',bindingInformation='*:443:site2.com']
appcmd set site /site.name:site2 /+bindings.[protocol='http',bindingInformation='*:80:site2.com']
appcmd set site /site.name:site2 /+bindings.[protocol='https',bindingInformation='*:443:www.site2.com']
appcmd set site /site.name:site2 /+bindings.[protocol='http',bindingInformation='*:80:www.site2.com']
In the script, I bound site site2 to Host headers site2.com and www.site2.com. I will explain later, in the Client side section, why did I need to bind to 2 names and why I chose these particular names.
You can see all your site binding with this command:
appcmd list sites
SSL certificate
As we’ve said, all sites with different Host headers will use the same SSL certificate. A regular SSL certificate is issued to a single server name. You will need to obtain a more expensive certificate that will work for multiple server names. If you don’t do this, you will get browser’s security warning on mismatching server name in certificate.
Client side
Now we are done with server side. How can the setting be tested?
There is no way how you can ask your browser to attach a Host header to the URL. But you can enter a record into your hosts file, located at %windir%\system32\drivers\etc :
127.0.0.1 site2.com
With this, if you navigate your browser to http://site2.com, your request will arrive to your web server with the Host header correctly set to site2.com.
Finally, you want the whole world to connect to your site without modifying hosts file. You need to do it on your DNS provider. Here you will appreciate the names for the Host headers that we chose above - site2.com and www.site2.com. When you point the domain name site2.com to your server IP address, the DNS provider will automatically set the Host header to site2.com. Likely, you want to access your site also with a www prefix. For this, the DNS provider will set the Host header into www.site2.com. That’s why we needed to bind our site2 in IIS to this header as well.