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:
 
image
 
 
 
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:
<bindings>

<binding protocol="https" bindingInformation="*:443:SNI.IIS8.com"sslFlags="1" />
</bindings>
 
 
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.
 
Using

  CCS
Using

  SNI
sslFlags
Description
0
0
0
Legacy SSL binding. Neither uses SNI nor CCS
0
1
1
SSL binding using SNI.
1
0
2
SSL binding uses CCS, but SNI is not enforced.
1
1
3
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
 
HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslSniBindingInfo
 
 
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           : SNI.IIS8.com:443

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