No need to enable SNI for multiple SSL sites on same IP but using same wild card certificate?

Question

I have an IIS server hosting:

example.com/www.example.com
sub1.example.com
sub2.example.com

They are listed as 3 separate sites under IIS, all bind to the same IP over HTTPS on 443. But they all use the same SSL certificate which is a wild card certificate covering *.example.com

In this scenario, my understanding is that SNI isn't necessary, because whichever certificate the server serves for any request (which is the same certificate) will work for all sites anyway, correct? I tested it myself and it seems to be working, but I just want to make sure doing so won't cause any unexpected ill results for certain users (I do not want to use SNI if possible because I do want Windows XP support for these sites)

Out of curiosity, I do want to know when you have a setup like this (multiple sites over SSL on same IP but not enable SNI), how exactly does IIS decide which certificate to serve (the first 443 binding on an IP? Or the last one used?)

Furthermore, if this setup works, in the future if I were to add example.org into the same IIS server, and using a different SSL certificate, can I enable SNI for example.org only and not affect the other 3 sites?

Solution 1

The rule of thumb is that at HTTP API level,

• You can bind a single certificate to IP:443 as IP based mapping.
• You can bind a certificate to domain:443 as SNI mapping.

Such mappings can be visually analyzed via Jexus Manager.

When SSL/TLS handshake starts, SNI mappings would be scanned first to match the host name in the request (from SNI aware browsers). If no SNI mapping matches, then the IP based mapping is scanned. That's the order of resolution.

The mappings are created and updated when you configure sites in IIS Manager. However, such mappings in HTTP API are separate from IIS configuration. They can exist even if sites in IIS are removed.

In your case, as you only have a wildcard certificate, configuring multiple sites in IIS Manager won't overwrite the IP based mapping, and should work flawlessly .

However, when you try to configure the second domain with another certificate, you cannot use the same IP address (as that IP:443 mapping already exists). If you force to configure that in IIS Manager, then the previous certificate should be overwritten. Of course, SNI mapping can be used then.

Solution 2

Technically speaking, no, SNI is not necessary because all yours websites share the same certificate. IIS is smart enough (it seems, at least) to distinguish between websites using Host: HTTP header on non-SNI clients (and maybe even in SNI-enabled clients), so everything is working as expected.

For the certificate "precedence", you can see which certificate is used by issuing netsh http show sslcert, and the default certificate (for non-SNI client) can be chosen by disabling the Require Server Name Indication option for that specific website (on website bindings settings window). More info here: https://stackoverflow.com/questions/19565961/default-certificate-for-sni-server-name-indication

This should answer also to your third question: if you add another website with SNI, there will be no changes to the existent websites (of course, by using a different domain and a different certificate, example.org will be reachable only by SNI-enabled clients)

Comments

[thankyoussd]

Thanks. I have require SNI disabled for all 3 sites, which all bind to the same IP, so I was wondering exactly whose certificate IIS uses as the default one (even though in this cases they're all the same). netsh http show sslcert shows the IP:443 entry uses the said certificate of course, but in this case it won't tell from which site the certificate was pulled from. Searching online shows that if there is a default 443 wildcard * bind site in IIS, that binding always takes precedence, but what if there isn't one? Just want to make sure about these things so the behaviors can be predicable.

[Admin]

According to that StackOverflow reply (and Microsoft documentation), to have a predictable behavior you need to leave SNI off for the only one binding (website) that you want to use when SNI is not supported on the client