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.