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

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)