SNI on IIS 8

SNI on IIS 8
IIS 8 supports Server Name Indication. This is enabled by default and no separate installation is required. Now while adding a HTTPS binding for a website on IIS 8, the option to enable SNI is available. This is how the UI looks like:
There are 2 things to remember when enabling SNI for a specific site on the server.
  • Selecting the above option enforces the site to use SNI i.e., it will expect the client to send a server_name as the part of the Client Hello during SSL handshake. If the server_name extension is not present then the SSL handshake would fail.
  • The hostname has to be provided, this is a strict mandate. The server will use this information to associate an incoming request to a specific site.
 How does the IIS know if a specific binding uses SNI?
When a SSL bindings is added for a site, there is also a small change in the configuration file i.e., the applicationhost.config. This is how the binding section looks like:

<binding protocol="https" bindingInformation="*"sslFlags="1" />
The highlighted attribute called sslFlags is. This attribute tells IIS what type of binding it is. This flag can be thought of as a doing an OR operation on 2 variables x and y. Below table would give you a gist of what this flag signifies.


Legacy SSL binding. Neither uses SNI nor CCS
SSL binding using SNI.
SSL binding uses CCS, but SNI is not enforced.
SSL binding uses CCS, but SNI is enforced.
Changes in Registry
In IIS 8 we have a new registry key where all the SNI bindings are stored. I had mentioned this in my previous blog post. This location of this registry key is
Executing the following command “netsh http show sslcert” will read this key and show a formatted output as shown below:
C:\>netsh http show sslcert
SSL Certificate bindings:

Hostname:port           :

Certificate Hash                : 8d90a17d2851f802b0a5619bf695b03544b8f5cb

Application ID                  : {4dc3e181-e14b-4a21-b022-59fc669b0914}

Certificate Store Name       : My

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check                  : Enabled

Revocation Freshness Time    : 0

URL Retrieval Timeout        : 0

Ctl Identifier               : (null)

Ctl Store Name               : (null)

DS Mapper Usage                 : Disabled

Negotiate Client Certificate    : Disabled 
So now we have 3 types of SSL bindings:
  1. IP:Port – Legacy SSL binding.
  2. Hostname:Port – SSL binding using SNI. (new in IIS 8)
  3. Central Certificate Store – SSL binding using Central Certificate Store. I will discuss this in detail in my next blog. (new in IIS 8)
There is a small problem that the administrators have to take care of while configuring SSL bindings to use SNI. If a non-SNI compliant browser connects to a site on which SNI is enforced, as I mentioned earlier the SSL handshake would fail.
To tackle this there is a fall-back mechanism in IIS where the it would try to determine a binding with the combination of IP:Port, if this is not present, then the SSL handshake fails. For this the IIS admin has to configure a binding which neither uses SNI nor CCS.
If legacy binding doesn’t exist, then the IIS UI will throw an alert as shown below. This message is a warning saying that there is no legacy binding, so in case of a failure the SSL handshake would fail.

Add Feedback