3

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

  • You're missing some important information. In particular you show a configuration with an RFC1918 address but a test from a public IP address. How are you handling the networking? – Michael Hampton Apr 15 '15 at 21:05
  • Also, if you're running a public e-commerce site, this might not be an issue. In most of the world there is virtually no usage of IE on Windows XP on the public Internet (with notable exceptions like China) as nearly everyone has switched to alternate browsers, and even within enterprises that are still stupidly running XP, IE8 is sometimes restricted to intranet sites, with another browser used for public Internet browsing. – Michael Hampton Apr 15 '15 at 21:08
  • They're on a godaddy dedicated server with the external public IP mapped through to the internal IP. Regarding IE8 he company this site is for seems to be still using it so it needs to come up for them. – Simon Apr 15 '15 at 21:11
  • OK, I know what's going on. For this to work, you can only have one UCC certificate per public IP address, with every host listed on it. If you have two on the same public IP address, then SNI will be required regardless of your settings. And of course the company needs to get rid of XP, a year or more ago. You might be willing to work around their irresponsibility, but the rest of the world is not, and they're going to continue to have more and more difficulty the longer they keep those antiques. – Michael Hampton Apr 15 '15 at 21:13
  • @MichaelHampton They already each have their own public IP (one for each UCC). Everything is working fine except one of the 'families' of sites reports 'this site works only in browsers with SNI support' and the other doesn't. The one that doesn't have this light blue bar works just fine in XP – Simon Apr 15 '15 at 21:53
1

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.