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

Simon
  • 1,301
  • 2
  • 15
  • 19
  • 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
  • Then they need to be mapped to separate private IPs. Otherwise it looks to the webserver like everything is on one IP. – Michael Hampton Apr 15 '15 at 21:54
  • They are :-) I feel like this is some obscure bug - but it's hard to for instance start from scratch since the sites are all live. Do you think there's a way to disable SNI completely and then reboot - maybe some registry entry. It's not in 'add/remove features' – Simon Apr 15 '15 at 21:55
  • Are you sure they're on separate IPs, and that you have them all mapped correctly? You did not show this configuration. – Michael Hampton Apr 15 '15 at 21:59
  • All sites have been up for over a year. Something slightly fishy is going on that if I hit the IP directly for both with http:// then they both come up but if I use https:// with the IP then for the site showing 'SNI required' I get `ERR_CONNECTION_RESET` even in Chrome 42 on Win 8. But I suppose that makes sense since IIS thinks it is requiring SNI. I'm going to try and 'stop' all websites and try to start them selectively. – Simon Apr 15 '15 at 22:12
  • Something screwy's going on. IIS just quit on me about 4 times when starting or stopping different websites. Slightly surprisingly even when the sites were all stopped I could still pull up the SSL cert by IP address where I would have expected it to not come up. I may need to try another reboot when everyone's gone home. – Simon Apr 15 '15 at 22:22
  • @MichaelHampton finally figured it out - thanks for your help, time and suggestions – Simon Apr 16 '15 at 02:01

2 Answers2

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

Simon
  • 1,301
  • 2
  • 15
  • 19
0

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.

jpaugh
  • 231
  • 5
  • 15
  • Yes but this was a long time ago and I needed to still support IE on XP. Fortunately don’t need to worry about things like that anymore. – Simon Jun 08 '20 at 21:18
  • Although since IIS is tied to the OS they never fix things like this https://serverfault.com/questions/320495/iis-7-still-serving-old-ssl-certificate/768974 – Simon Jun 08 '20 at 21:20
  • 1
    Since you're revisiting this, would you mind accepting your own answer? I didn't see that [you had found a solution](https://serverfault.com/questions/683016/cannot-disable-sni-on-windows-server-2012/1020587?noredirect=1#comment839917_683016) until after I posted my answer. – jpaugh Jun 08 '20 at 21:22
  • 1
    Thanks for taking the time to add what you did :) – Simon Jun 08 '20 at 21:39