Ssl – Can wildcard and single domain certificate coexist for the same domain

In this case you would need separate ports if they were on the same IP, or separate IPs if you wanted them on the same standard SSL port (443). IIS doesn't support reading host headers and redirecting using SSL. You can use the same wildcard certificate without any issue, but you would need something inbetween IIS and the client (like Microsoft Forefront Threat Management Gateway) in order to do routing by hostname over SSL. (I hope that makes sense)

The reason this happens is because the connection is encrypted and the certificate is validated before the HTTP header is actually sent, so at that time IIS has to know what site it's using beforehand. Now, Firefox does send the hostname in with the initial encryption request but I'm not sure if IIS supports that (or if any other browsers do).

The First Few Milliseconds of a HTTPS Connection has an incredibly in depth description on how HTTPS generally works (through a special debug build of Firefox). As you can see a few paragraphs in TLS supports a server name extension, but as far as I know IIS does not support that extension.

Baris is right! The SSL certificate configured on an IP:PORT binding (example: 100.74.156.187:443) always takes precedence in http.sys! So the solution is as follows:

Do not configure an IP:443 binding for your wildcard-fallback-certificate but configure a *:443 binding (* means "All Unassigned") for it.

If you have configured your wildcard certificate on the Azure Cloud Service SSL endpoint (as i have) you have to change the SSL binding created by the Azure Cloud Service Runtime (IISconfigurator.exe) from IP:PORT to *:PORT. I am calling the following method in OnStart of my web role:

public static void UnbindDefaultSslBindingFromIp()
{
    Trace.TraceInformation(">> IISTenantManager: Unbind default SSL binding from IP");
    using (var serverManager = new Microsoft.Web.Administration.ServerManager())
    {
        try
        {
            var websiteName = string.Format("{0}_Web", Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.CurrentRoleInstance.Id);
            var site = serverManager.Sites[websiteName];
            var defaultSslBinding = site.Bindings.Single(b => b.IsIPPortHostBinding && b.Protocol == "https");
            defaultSslBinding.BindingInformation = string.Format("*:{0}:", defaultSslBinding.EndPoint.Port);
            serverManager.CommitChanges();
        }
        catch (Exception ex)
        {
            Trace.TraceError(ex.ToString());
        }
    }
}

The following screenshot shows a working configuration of our cloud service. Please don't be confused about the non-standard ports. The screenshot is from the emulated cloud service.

One further thing to mention: Do not change all bindings to * because the HTTP (port 80) binding only works with IP:PORT binding in the deployed cloud service. Something else is bind to IP:80 so *:80 does not work because * stands for "all unassigned" and the IP is already assigned somewhere else in http.sys.