Home / server / Questions / 683016
Accepted
Simon
Asked: 2015-04-16 12:46:43 +0800 CST

Cannot disable SNI on Windows Server 2012

  • 772

I have two different 'families' of related sites, each with their own UCC certificate on the same server.

I'm hosting them on the same IIS server, using one IP address for each family.

Both UCC certficates are from GoDaddy.

Every one of the bindings (for each SAN in the UCC) has 'Require Server Name indication' disabled.

enter image description here

However when I try to hit the site from IE 8 on Windows XP only one of the 'families' of sites works. The other just doesn't negotiate.

When analyzing the SSL on SSLLabs.com I get the following result - telling me 'This site works only in browsers with SNI support.'

But how is this possible! I have disabled 'Require SNI' for every :443 binding.

I've even looked at the applicationHost.config file and there isn't a single site with sslFlags="1" to indicates this setting is enabled. Yes I also restarted IIS.

What's going on. I'm very stumped. I'm wondering if I can completely disable SNI on the server somehow, or what would have triggered this to happen. I did several months of Windows updates yesterday, but to be frank I think it has been this way for a long time without me realizing - based on $0 in sales from IE8 XP clients ;-)

Edit: I'm really thinking my IIS has become corrupted. When I run netsh http show sslcert every single binding is of the form IP:port. According to this article if SNI is enabled then I would see hostname:port and I see no entries in this format. There's also no entries in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslSniBindingInfo in the registry - but I confirmed that a new one is created here if I temporarily add an SNI binding.

IP:port                      : 10.0.0.2:443
Certificate Hash             : d59a149e6678bc10d62093401c5b705cc23094be
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

enter image description here

iis

2 Answers

  1. Best Answer

    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 :-)

    enter image description here

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

    • 1

  2. You said,

    I'm hosting them on the same IIS server, using one IP address for each family.

    This is exactly the scenario SNI was designed for.

    SNI [...] allows a server to present multiple certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites (or any other service over TLS) to be served by the same IP address without requiring all those sites to use the same certificate.

    Because the sites share the same IP address and port, the only way to distinguish them is by domain name. But, without SNI support, the server doesn't have access to the domain name at the time it decides which certificate to send to the client. This is because the client has not yet sent the request, and the domain name is properly a part of an HTTP request.

    • 0