Windows Server 2012 : Scalable and elastic web platform (part 2) - Server Name Indication

2. Server Name Indication

In previous versions of IIS, you could use host headers to support hosting multiple HTTP websites using only a single shared IP address. But if you wanted these websites to use Hypertext Transfer Protocol Secure (HTTPS), then you had a problem because you couldn’t use host headers. The reason is that host headers are defined at the application level of the networking stack, so when an incoming HTTPS request containing a host header comes to a web server hosting multiple SSL-encrypted websites, the server can’t read the host header unless it decrypts the request header first. To decrypt the request header, the server needs to use one of the SSL certificates assigned to the server. Now, typically you have one certificate for each HTTPS site on the server, but which certificate should the server use to decrypt the header? The one specified by the host header in the incoming request. But the request is encrypted, so you basically have a chicken-and-egg problem.

The recommended solution in previous versions of IIS was to assign multiple IP addresses to your web server and bind a different IP address to each HTTPS site. By doing this, host headers are no longer needed, and IIS can determine which SSL certificate to use to decrypt an incoming HTTPS request. If your web server hosts hundreds (or even thousands) of different HTTPS websites, however, this means that you’ll need hundreds or thousands of different IP addresses assigned to the network adapter of your server. That’s a lot of management overhead—plus you may not have that many IP addresses available.

IIS 8 in Windows Server 2012 solves this problem by providing support for Server Name Indication (SNI), which allows a virtual domain name (another name for a host name) to be used to identify the network end point of an SSL/TSL connection. The result is that IIS can now host multiple HTTPS websites, each with their own SSL certificate, bound to the same shared IP address. SNI therefore provides the key benefit of increased scalability for web servers hosting multiple SSL sites, and it can help cloud hosting providers better conserve the dwindling resources of their pool of available IP addresses.

Both the server and client need to support SNI, and most newer browsers support SNI as well. Note, however, that Microsoft Internet Explorer 6 doesn’t support it.

Configuring SNI

SNI can be configured on a per-site basis by editing the bindings for each HTTPS site from the IIS Manager console. Simply select the Require Server Name Indication check box as shown in Figure 2 and type a host name for the site, while leaving the IP Address setting as All Unassigned to use the single shared IP address on the server.

Figure 2. Configuring SNI on an SSL site.

SSL configuration and its order of applicability

SSL configuration and IIS network binding configuration are actually two separate and completely disconnected configurations on Windows. So when working on SNI, as well as Centralized SSL Certificate Support, new SSL configurations have been introduced.

At a high level, there are four SSL binding types, and they are applied in the following order:

Order	Syntax	Description
1	IP:Port	An exact IP:port SSL configuration is found. MY/LM or MY/Web Hosting certificate stores are used.
2	Hostname:Port	An exact hostname:port SSL configuration is found. This is the SNI configuration and is applied only if SSL connection is initiated by an SNI-capable client. MY/LM or MY/Web Hosting certificate stores are used.
3	CCS:Port	This is the Centralized SSL Certificate Support (CCS) configuration. In this configuration, a CCS provider is used to locate the SSL certificate. By default, IIS provides a file-based CCS provider.
4	[::]:Port	IPv6 wildcard match and the connection must be IPv6.
5	0.0.0.0:Port	IPv4 wildcard match and the connection can be either IPv4 or IPv6.

For example, consider the following configuration in IIS:

      <site name="mySNIsite" id="1" serverAutoStart="true">
      <application path="/" applicationPool="snidemocert0">
         <virtualDirectory path="/" physicalPath="C:\inetpub\wwwroot" />
      </application>
      <bindings>
         <binding protocol="https" bindingInformation="192.168.0.1:443:w
ww.mycontoso.com" />
      </bindings>
   </site>

With the following SSL configuration, this code is used:

   IP:port                 : 192.168.0.1:443
Certificate Hash        : 2114e944c1e63dcdcd033e5d3fdb832ba423a52e


   Hostname:port           : www.mycontoso.com:443
Certificate Hash        : 0e62ac0f4deb8d6d78ac93a3088157e624ee540b

In this example, the first SSL certificate (as referenced by 2114e944c1e63dcdcd033e5d3fdb832ba423a52e) would be used because the IP:Port (192.168.0.1:443) configuration precedes Hostname:Port (www.mycontoso.com:443).

Won Yoo, Principal Program Manager

Jenny Lawrance, Software Design Engineer II

Eok Kim, Software Design Engineer II

Aniello Scotto Di Marco, Software Design Engineer in Test II