1

I found a good resources over at a Microsoft blog which goes into detail about IIS, SNI, and even some CCS:

https://blogs.msdn.microsoft.com/kaushal/2012/09/04/server-name-indication-sni-with-iis-8-windows-server-2012/

It's a great resource. I read it thoroughly and the comments. Based on the content in that blog, I think I know the answer, but it doesn't hurt to get another pair of eyes, as the saying goes.

I have a box with Windows Server 2012, IIS 8.5. One IP address. It contains one Site with two SSL bindings. That is, HTTPS. Both are over port 443 and each one has its own unique certificate. And since there is only one IP, they each share the same IP. One binding has Require Server Name Indication checked and Host name has an entry of myserver.example.com. The other binding is the default SSL binding and thus Require Server Name Indication is unchecked and Host name is empty.

(As an aside, based on the content in said blog, I think we can answer the question of what happens if Host name is entered but Require Server Name Indication is unchecked. Nothing. It reverts to IP:Port.)

The question I have is it is possible to mix SNI and non-SNI SSL bindings on the same IP:Port?

Based on the workflow described in the blog (see below) and my own testing, no, it'll always choose the non-SNI SSL binding. But maybe I'm wrong and there is a solution I'm not seeing for mixing SNI and non-SNI bindings with same IP:Port.

    Below are the steps involved during SSL handshake between a SNI
    compliant Client and a site hosted on IIS 8 on which a SSL binding is 
    configured to use SNI.

    1. The client and the server establish a TCP connection via TCP 
       handshake.

    2. The client sends a Client Hello to the server. This packet contains 
       the specific protocol version, list of supported cipher suites along 
       with the hostname (let’s say www.outlook.com provided its a SNI 
       compliant browser). The TCP/IP headers in the packet contain the 
       IPAddress and the Port number.

    3. The server checks the registry (legacy bindings) to find a 
       certificate hash/thumbprint corresponding to the above combination of 
       IP:Port.

    4. If there is no legacy binding for that IP:Port, then server uses 
       hostname information available from the Client Hello checks the 
       registry to find a certificate hash corresponding to the above 
       combination of Hostname:Port. The server checks the below key to find 
       the combination:

        HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslSniBindingInfo

    5. If the above step fails i.e., if the server couldn’t find a 
       corresponding hostname:port, then it would use the IPAddress 
       available to search for a legacy SSL binding for that IPAddress and 
       PORT. (If this is absent then the SSL handshake would fail)

    6. Once it finds a match, the crypto API’s are called to retrieve the 
       Server Certificate based on the thumbprint/certificate hash from the 
       certificate store. The retrieved certificate is then added to the 
       Server Hello and sent to the client.
user3621633
  • 161
  • 6
  • 1
    You can definitely mix them, as long as there is no conflict, https://docs.jexusmanager.com/tutorials/https-binding.html#background – Lex Li Feb 27 '19 at 20:38
  • Thanks for the link. Unfortunately, I'm not able to reproduce what's in that article. I also don't have IIS Express and I don't know what HTTP API is. That sounds like a custom module for Jexus Manager. I'm not able to find HTTP API in the Web Platform Installer. Per the author of that Microsoft blog (works at Microsoft), the order of precedence is it checks IP:Port first. So, if this module gets around that, my guess is it's not created by Microsoft but by Jexus Manager and thus I cannot reproduce. Thanks again for your help. – user3621633 Feb 27 '19 at 21:06
  • 1
    That's an exclusive feature of Jexus Manager, but you can run `netsh` command to get the same information. Notice that SNI bindings are not in IP:Port format, but domain:port format. – Lex Li Feb 27 '19 at 21:11
  • Thank you. Correct. I'm able to get SNI information via `netsh`, no problem. But without a custom module or some other custom solution, it looks like the order of precedence in IIS is IP:Port and then Hostname:Port. Like the module, I trust I could create a .NET app that attaches itself to IIS and intervenes during the request and looks for HostName:Port first. But out-of-the-box, doesn't look like that's the case, unfortunately. Thanks again. – user3621633 Feb 27 '19 at 21:56
  • "it looks like the order of precedence in IIS is IP:Port and then Hostname:Port." With all such materials ahead, I wonder why you still went to a totally wrong conclusion. – Lex Li Feb 27 '19 at 21:57

0 Answers0