A: Server Name Indication (SNI) is an extension to the SSL/TLS protocols that lets an SSL/TLS client (for example, a browser) indicate the exact hostname it tries to connect to at the start of the SSL/TLS handshaking process. On the HTTP server side, it lets a web server host multiple secured websites that are using the same IP address and port number without requiring those sites all to use the same SSL/TLS certificate. As I'll explain, SNI is designed to allow more flexibility and better scalability when using SSL/TLS in a multi-tenant web hosting environment.
To understand the value of SNI, you must understand some of the underlying SSL/TLS protocol particularities and limitations. During the setup of an SSL/TLS connection, the client always requests a certificate from the web server. By comparing the name it tries to connect to with the name or names that are included in the server certificate, the client can better protect its web users against man-in-the-middle (MITM) attacks. If the client detects a naming mismatch, it aborts the connection because that might indicate an attempted MITM attack.
To limit the number of certificates needed for web-based solutions that require multiple certificates (for example, a unified communications infrastructure), a single X.509 certificate can be linked to multiple host and domain names. This method is possible thanks to the X.509 v3 specification's support for the subjectAltName field, which allows one certificate to specify more than one host or domain name, and the support for wildcards in both the common name and subjectAltName fields.
In large web hosting environments or multi-tenant clouds where the hosted websites regularly change, it might be impractical or simply not allowed to use a single certificate for all websites that are hosted on a single server. These environments require certificates where each certificate is linked to a different name but to the same IP address.
HTTP supports a mechanism -- HTTP host headers -- that lets a web client request a connection to a specific name from a server that hosts different web servers on the same IP address. However, this mechanism can't be used with SSL/TLS connections. This limitation is because when using HTTPS, the SSL/TLS handshake happens before the web server can see the information in the HTTP headers.
The result is that web servers often can serve only one domain name or a small number of domain names per IP address for HTTPS-based browsing and need multiple certificates that are linked to different IP addresses. This situation increases the costs for website hosters: primarily because they need to submit requests for extra IP addresses to their local Internet registry.
SNI fixes this problem by allowing an HTTP client to send a domain or host name as part of the SSL/TLS handshake process so that the server can select the correct domain or host early in the SSL/TLS setup and present the browser with the server certificate that contains the correct name. As such, the web server can use a single IP address to serve the different domain or host names that are linked to different server certificates.
Microsoft included SNI support in IIS 8, which is bundled with Windows Server 2012. On the browser side, most current browsers (i.e., browsers released in the past 5 years) support SNI. One notable exception to which browsers work with SNI is any version of Internet Explorer (IE) that runs on Windows XP.
To enable configuration of SNI on an IIS 8 web server, Microsoft included new options in the configuration screen for creating a new website and in the Site Bindings dialog box of existing websites. They now both have a new check box that lets you enable or disable SNI for a secured website, as Figure 1 illustrates for the Add Website configuration dialog box. The code supporting SNI is part of default IIS installation; there's no need to install additional features.
Figure 1: Configuring SNI in the Add Website dialog box for IIS 8 (Click image for larger view)
In Windows Server 2012, Microsoft also included a new Web Hosting certificate container in a Windows Server 2012 server's machine certificate store. The difference between this new container and the legacy Personal container is that the Web Hosting container is designed to scale to a higher numbers of SSL/TLS certificates. Another technical tweak that will benefit SSL/TLS scalability is that in Windows Server 2012, certificates are loaded in memory on-demand. In previous versions of Windows Server, all certificates were pre-loaded in memory at the first HTTP GET request that the web server received.
