Understanding XP users accessing a UCC certificate on IIS8

Simon asked:

I have a single IIS website which hosts 3 different websites all using the same UCC SSL certificate. (The code of my site examines the host header itself to decide which variation of the site to show).

I fixed my most fatal mistake already for my Internet Explorer users on XP which is to disable the ‘Require Subject Name Indication’ field in IIS. Since SNI is not supported on Windows XP if it were enabled when an XP user switched to HTTPS they would basically get kicked off the site with no warning (don’t tell my boss).

So I completely understand that when a user accesses any one of the 3 sites via HTTPS that all share the same IP, he is sent to the same IIS site and served the UCC certificate. Even XP supports UCC/SAN certificates so the client accepts the certificate and shows the site as expected.

Now…. forget all that and consider a second non hypothetical scenario.

  • Lets pretend I have two sites : cats.com and dogs.com
  • They’re different sites and are deployed in two different
    websites in IIS 8.
  • They’re both on the same UCC SSL certificate*
  • SNI is disabled
  • They are both bound to the same IP address

Now consider XP users accessing https://cats.com

Here’s how I understand things work:

  • DNS gives the browser back my IP – lets say
  • An HTTPs connection is negotiated,but because XP doesn’t know anything about SNI it isn’t sending an SSL host header (or whatever they’re called) but just accessing the secure site via the IP.
  • So IIS will look for that IP associated with an https website binding, and it will actually find TWO.
  • Let’s say IIS decides to just serve you the first one – so it gives you cats.com which is what you’re expecting. So that’s fine.
  • BUT lets say you go to https://dogs.com – shouldn’t you be actually served the site for cats.com because SSL on XP doesn’t know about SNI for SSL connections and anyway it’s disabled in IIS?

Well you don’t. You get dogs.com. I’ve tried this, and cats.com and dogs.com both work from a Windows XP Internet Explorer 8 client.

I just don’t understand why this works. I would have expected this behavior only in my first scenario when they all share a single IIS application.

My best guess is that IIS 8 is receiving the host header anyway and being smart enough to route it to the correct website and finds a UCC certificate name. Is that what’s happening?

Can someone explain further?

* just to deliberately annoy techically minded cat and dog owners 😉

My answer:

IIS uses the HTTP Host: header to determine which web site to serve, just as with any other request.

View the full question and answer on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.