HTTPS Host Name for IIS


The configuration of an IIS site includes the ability to associate a host name with a particular site definition. For HTTP traffic this allows multiple web sites to be hosted at the same IP address and port, with the true domain name of the site mapped using the host name header. For example, if you have a limited number of IP addresses available and many domains that you want to host all on port 80, then you can specify a different host header for each site to distinguish the traffic.

However, for HTTPS the ability to provide host headers is disabled in the interface. There are two different (but related) reasons for this difference in behavior.

First, the typical HTTPS certificate is usually generated for a single fully qualified domain name. Getting a certificate that has a wildcard in the domain name or that has multiple listed common names usually requires additional requirements by the certificate authority before being issues. If you didn’t know to ask for this, then you probably don’t have the right type of certificate for hosting multiple HTTPS sites. A certificate against a single name doesn’t need configuration to be used because there is only one valid value that you could use it with.

Second, the infrastructure for processing certificates is actually bound to the IP address and port rather than the site. Certificate processing is largely complete by the time the HTTP kernel driver hands the request off to the web server. A decision about how to process the message needs to be made before IIS has a chance to apply its service configuration. This is not a simple layering problem of the implementation but rather something more fundamental about the protocol. In order for IIS to extract the information from the message that it needs to identify the site, the certificate processing needs to be done first so that the decrypted message can be examined. Changing the order of steps to solve the original problem would simply create a new problem.

Fortunately, the loose coupling between the HTTP driver and the IIS host header configuration aids in solving the problem of order. If you have a properly provisioned certificate, then the message can be seen to match one of the provided names even if the HTTP driver doesn’t know which. This allows the mapping to be deferred until the site configuration and decrypted information are both available. The interaction between the different layers of the stack pushes the scenario beyond the limits of what the user interface makes easy though.

Comments (2)

  1. Paul says:

    This is a wonderful post on an interesting problem that I’ve run into before. If you would, a follow up post that explores the concepts mentioned in the last paragraph in greater depth would be tremendously helpful. Specifically, I’m interested in learning how to request and properly provision an appropriate certificate as well as how to take advantage of this under IIS. Finally, does Remote Desktop Gateway support this configuration (with or without IIS on the same box)?

    Thanks again,

    Paul

  2. Matt Davis says:

    There’s a TLS extension that solves this problem once and for all: SNI (Server Name Indication). It allows a hostname to be passed during the TLS handshake, so an SNI-aware stack can dynamically select the right certificate to present. It’s a chicken-and-egg problem, however- it won’t be widely adopted by clients until more servers support it, and it won’t be implemented by servers until more clients support it. Apache and Firefox have supported it for a few years, but to my knowledge, IIS/HTTP.sys still don’t, and IE only supports it on Vista and higher (only in protected mode). I’m sure there’s a good reason Microsoft has chosen to ignore SNI for all these years, but Windows seems to be the one holding up the parade these days. It makes me throw up in my mouth a little every time I have to configure an Apache box in front of my WCF services to support SNI for internal use. 🙂