Server Name Indication is an extension of SSL and TLS that indicates at the beginning of the handshaking process which hostname the client is seeking connection to. This makes it possible for the server to present multiple certificates, and thereby connect different websites with SSL security to one IP address and port (port 443). The use of SNI eliminates the need for the use of separate IP addresses for each website with SSL security on a web server.

Background to the problem

When making an SSL/TLS connection, the client requests a digital certificate from the server. Once the server sends the certificate, the client compares the name it was trying to connect to with the name included in the certificate. If a match is found, the connection runs normally. If no match is found, the user can be alerted to the discrepancy and disconnected. The mismatch can indicate an attempt at a man-in-the-middle attack. Name-based virtual hosting allows multiple DNS hostnames to be hosted by a server (usually a web server) on the same IP address. To do this, the server uses a hostname obtained from the client as part of the protocol (for HTTP, the name is included in the host header). However, when using HTTPS, the SSL/TLS handshake takes place before the server sees HTTP headers. Therefore, it is not possible for the server to use the information from the HTTP host header to decide which certificate to show. Domain names with the same IP address must therefore use the same certificate. Server Name Indication (SNI), an extension of TLS, addresses this problem by sending the virtual domain name as part of the TLS negotiations. This allows the server to select the correct virtual domain and present the correct certificate to the browser. Therefore, the clients and servers that support SNI allow a single IP address, with different certificates, to be used for different domain names.

Support

To use SNI, the SSL/TLS library used by an application must support SNI and the application must pass the hostname to the SSL/TLS library. One downside is that the SSL/TLS library can be sent as part of the request and as part of the operating system. As a result, some browsers support SNI on all operating systems and others only on specific operating systems. As of 2011, most web browsers and SSL libraries have implemented support for SNI, but there are still a large number of users who have a browser/operating system combination that it doesn’t support. The following combinations do not support SNI:

Client Side

• Internet Explorer (any version) on Windows XP
• Safari on Windows XP
• BlackBerry Browser
• Windows Mobile up to 6.5
• Android default browser on Android 2.x

Server Side

• IBM HTTP Server

The following combinations do support SNI:

Client Side

• Internet Explorer 7 or later, on Windows Vista or later. Does not work on Windows XP, not even in Internet Explorer 8.
• Mozilla Firefox 2.0 or later
• Opera 8.0 or later (the TLS 1.1 protocol must be enabled)
• Opera Mobile at least version 10.1 beta on Android
• Google Chrome (Vista or later. XP on Chrome 6 or newer)
• OS X 10.5.7 or later on Chrome 5.0.342.1 or later)
• Safari 2.1 or later (Mac OS X 10.5.6 or later and Windows Vista or later)
• Konqueror/KDE 4.7 or later
• MobileSafari in Apple iOS 4.0 or later
• Android default browser on Honeycomb or newer
• Windows Phone 7
• MicroB on Maemo

Server Side

• Apache 2.2.12 or later by using mod_ssl
• F5 Networks Local Traffic Manager with version 11.1 or later
• LiteSpeed 4.1 or later
• Pound 2.6 or later
• Apache Tomcat on Java 7 or later
• Microsoft Internet Information Server IIS 8
• PageKite tunneling reverse proxy

To use SNI, your browser must support TLS 1.0 and ensure that it is active. To activate TLS 1.0 in your browser, follow these steps: FireFox: Tools→ Options→ Advanced→ Encryption→ Use TLS 1.0 Internet Explorer: Tools→ Internet Options→ Advanced→ Use TLS 1.0 Safari: Safari→ Preferences→ Security icon→ Enable Plug-ins, Enable Java, Enable JavaScript