7

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?

kasperd
  • 30,455
  • 17
  • 76
  • 124
thankyoussd
  • 193
  • 1
  • 1
  • 3

3 Answers3

8

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)

kasperd
  • 30,455
  • 17
  • 76
  • 124
  • 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. – thankyoussd Apr 30 '18 at 23:29
  • 1
    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 –  May 02 '18 at 07:10
6

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.

Lex Li
  • 1,235
  • 8
  • 10
0

SNI is only not required when the same cert is used for all port 443 traffic (or whatever port you are listening on securely). SNI is not a negotiated thing, meaning unless you turned SNI off through registry edits on each client. The client will still send SNI if it supports the extension (which everything nowadays does). Turning off the requirement at the server doesn't change how the client behaves, only how the server behaves. If SNI is off at the server, the default cert is used all the time period. The server decides what cert to send to the client, the client just third-party validates it. For many webservers, if a default cert is not specified the first cert it loads with will serve that purpose if SNI is off at the server. The client doesn't choose the cert, the server does. The server cannot see the host header until decryption happens. The SNI extension in the client TLS negotiation requests, allows the server the option to choose a different certificate to send, so that the client correctly validates the domain against third-party CA. If the client never sends the SNI attribute, it doesn't matter how the server is set up, it is going to send the default certificate or fail the connection (depending on server behavior).

SNE
  • 1