IIS – Enabling OCSP Stapling on SNI-Enabled Site

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.

One thing I didn't mention was that I am using the IIS Centralized Certificate Store - which turned out to be important.

For my sites let's pretend they're the following groups (the IP is internal and mapped through the firewall).

Group A : red.com, blue.com, green.com   (UCC certificate A)  10.0.0.1
Group B : cat.com, dog.com, mouse.com    (UCC certificate B)  10.0.0.2

Group A is the group that was working as I wanted it to (not reporting that it requires SNI). Group B was not working on XP with IIS 8.

In my certificate store I have multiple copies of each certificate (just pfx files in the file system).

red.com.pfx blue.com.pfx green.com.pfx etc. for all the sites

When I ran the command netsh http show sslcert it turns out there was only an entry for 10.0.0.1:443 and not one for 10.0.0.2:443. This is what was causing the different behavior in each site.

IP:port                      : 10.0.0.1:443
Certificate Hash             : d4a17e3b57e48c1166f18394a819edf770459ac8
Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name       : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check                  : Enabled
Revocation Freshness Time    : 0
URL Retrieval Timeout        : 0
Ctl Identifier               : (null)
Ctl Store Name               : (null)
DS Mapper Usage              : Disabled
Negotiate Client Certificate : Disabled

Why was this IP showing an entry? I also had an additional binding in another website with this same cert for the same IP address (used to redirect non-SSL to SSL).

I guess IIS is assuming that if you're using the centralized store that you're using SNI so it seems to implicitly report that it requires it - even though it really doesn't.

I was able to [finally] solve this by changing one of my bindings for group B to explicitly reference the certificate instead of just looking for it it in the store. After doing this of course the 10.0.0.2:443 entry was then present in the netsh http show sslcert list and the site worked fine from XP :-)

(I only had to do this for dog.com. The other animal sites are still set to use the central store).