Sunday, December 4, 2011

SSL, IIS, and Host Headers

There is a lot of confusion about how IIS handles SSL.  With all the confusion out there, I thought I should put together a quick post.  This post will also explain the error message: At least one other site is using the same HTTPS binding and the binding is configured with a different certificate.

My discussions this week were specific to SharePoint, but the confusion is with host headers in IIS.  The crux of the issue is that when IIS receives a request, the host header is encrypted.  Therefore, IIS cannot determine which web site to route the request to.

Let’s start with a simple example without SSL.  Say that I have two URLs and  If I want to host them both on the same server, I have to set up bindings.  I can tell IIS to listen on a specific IP address and port combination, or I can use host headers.  See the image below.

If we look at the individual bindings, notice that IIS is listening on all IP addresses for any request to on port 80.

So, how does this work?  When your browser requests a page from, it first resolves the IP address from DNS.  Let’s say that IP address  Then, it sends a TCP packet to on port 80.  The body of the request looks like this.
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-US
User-Agent: Mozilla/5.0
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
When, IIS receives this request, it reads the last line, and routes it to the site, based on bindings we configured above.

Herein lies the problem.  Note that the host header (Host: only exists inside the body of the message.  If I sent this request over SSL, IIS would not be able to read the host header until it decrypted the message.  And, IIS cannot decrypt the message until it knows which site’s private key to use.  Alas, a catch 22.

Therefore, it would seem that I cannot use host headers with SSL.  In fact, notice that when I create an http binding, the host header is disabled.  So, it would seem that, if we use SSL, we can only create bindings based on the IP address and port.  In general this is true, but there is an exception: wildcard certificates.

A wildcard certificate is a certificate that can be used to secure multiple sub-domains.  For example, a wildcard certificate, created for * can be used for both and  Notice that when I select a wildcard certificate in IIS, the host header textbox is again enabled.

If you have been paying attention, you should be asking yourself: How does IIS know which certificate to use?  Now I have two sites that both use the same certificate, but IIS still needs to decrypt the message to determine if it is destined for one of the two site that use this certificate.  We could be hosting other site after all.

IIS does this based on the port number.   You can only configure one certificate per port.  First, IIS looks up the certificate based on the port the message was received on.  Next, it decrypts the message and reads the host header.  Finally, it uses the host header to route your request to the correct web site.

Note: that this only works with wildcard certificates and subdomains.  I cannot host and on the same server, because they do not use the same certificate.  Also, note that wildcard certificates only work for a single level.  Therefore, I cannot host using *

BTW: Have you ever received the warning message below?  When you try to configure a new https binding on a port that is already in use by another site, IIS warns you that you are about to change the SSL certificate for all sites listening on that port.


  1. You blog helped us to install a digital SSL certificate on Cpanel. Thanks for sharing with us! Waiting for further aid about SSL certificate

  2. By mistake I have selected yes at warning pop up now when i open 2nd website with https, it open 1st site but in address bar it showing 2nd website, please help me how i revert back this mistake.

  3. Grateful to check out your website, I seem to be ahead to more excellent sites and I wish that you wrote more informative post for us. Well done work.