Well, the title may not be entirely accurate. Honestly, I didn’t know what to title this post — let me explain what I observed and how I was able to get around the issue.
The default behavior in IIS is that you can only bind a SSL certificate to a specific site. And, by default, you cannot specify the host header value for the binding. What this means is that the SSL certificate is now bound to port 443 for all sites using the IP address specified. If you look at the screen shot below, you will notice that the Host name field is grayed out, and we are unable to populate this.
Causes
Here are sample bindings for the site in IIS:
- www.example.com
- 10.11.1.60:80 (http)
- 10.11.1.60:443 (https)
- example.com
- 10.11.1.60:80 (http)
The issue that I ran into is that I have multiple sites bound to a shared IP address. I then use the host name field to ensure the site is only listening to requests for specified host. As you probably know, this enables you to host multiple websites with a single IP address.
The other issue is that I only have a single site certificate bound to the www.example.com domain. The certificate is not valid for example.com. Due to the default behavior of IIS, when a user visits https://example.com they will receive a security warning because the fully qualified domain name (FQDN) for the SSL certificate was issued for www.example.com, not example.com.
Solutions
There are several possible solutions for the issue:
- Do not bind multiple sites to a single IP address. Dedicate an IP address to each site that uses HTTPS.
- Purchase a wildcard certificate to cover the example.com domain, and all subdomains (including www). This will enable you to specify the host name when setting the site binding.
- Let IIS think think you have a wildcard certificate. This hack will enable you to set the host name value for the single site certificate for the site binding.
Let me quickly review each option.
Option 1: Definitely possible, but there are often additional expenses associated with purchasing/leasing multiple IP addresses.
Option 2: This is the best solution if you have multiple subdomains. You can also get a UCC SSL certificate for up to 5 or 10 subdomains, which may be less expensive than purchasing a wildcard certificate.
Option 3: This is a cool hack that enables us to specify the host name value. However, please note that if we want to redirect from ”https://example.com” to ”https://www.example.com” (or vice versa), then you will still need to have SSL certificates for both FQDNs.
Host Name Hack
I’m not sure if this is a hack, a bug, or a “feature”. But nonetheless let’s take a look at how to enable the host name value field in the IIS site binding. To summarize the following steps, we will be updating the certificate’s friendly name to start with an asterisk ( * ).
- Start > Run > mmc
- File > Add/Remove Snap-in…
- Choose Certificates and then click on the Add > button
- A Certificates snap-in window will open, choose the Computer account and click Next > and then Finish
- Click OK to close the Add or Remove Snap-in window.
- Browse to your SSL certificate. It is likely located under Personal > Certificates
- Right-click on the certificate and choose Properties
- Change the Friendly name so that their is a leading asterisk ( * ).
Please note, this does not change your certificate. It is still only valid for the FQDN that you requested when you submitted the certificate signing request to your SSL provider. It also does not instantly turn this certificate into a UCC or wildcard certificate. It only enables us to now modify the host name value for the binding in IIS.
By prepending the certificate friendly name with an asterisk, we are now able to set the host name value in the IIS binding.