Picture of Brian Love wearing black against a dark wall in Portland, OR.

Brian Love

IIS and HTTPS Binding with Host Header

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.

The default behavior for binding an SSL certificate is to only allow the certificate to be bound to a single site, without a host name specified.


Here are sample bindings for the site in IIS:

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.


There are several possible solutions for the issue:

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 ( * ).

Prepend the certificate friendly name with an 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.

Set host name value.

By prepending the certificate friendly name with an asterisk, we are now able to set the host name value in the IIS binding.