Server Name Indication
Server Name Indication (SNI) is an extension to the TLS computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites (or any other Service over TLS) to be served off the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS.
To make use of SNI practical, the vast majority of users must use web browsers that implement it. Users whose browsers do not implement SNI are presented with a default certificate and hence are likely to receive certificate warnings, unless the server is equipped with a wildcard certificate that matches the name of the website.
Background of the problem
When making a TLS connection the client requests a digital certificate from the web server; once the server sends the certificate, the client examines it and compares the name it was trying to connect to with the name(s) included in the certificate. If a match occurs the connection proceeds as normal. If a match is not found the user may be warned of the discrepancy and the connection may abort as the mismatch may indicate an attempted man-in-the-middle attack. However, some applications allow the user to bypass the warning to proceed with the connection, with the user taking on the responsibility of trusting the certificate and, by extension, the connection.
It is possible for one certificate to cover multiple hostnames. The X.509 v3 specification introduced the subjectAltName field which allows one certificate to specify more than one domain and the usage of wildcards in both the common name and subjectAltName fields. However it may be impractical—or even impossible, due to lack of a full list of all names in advance—to obtain a single certificate that covers all names a server will be responsible for. As such a server that is responsible for multiple hostnames is likely to need to present a different certificate for each name (or small group of names). Since 2005, CAcert has run experiments on different methods of using TLS on virtual servers. Most of the experiments are unsatisfactory and impractical. For example, it is possible to use subjectAltName to contain multiple domains controlled by one person in a single certificate. Such "unified communications certificates" must be reissued every time the list of domains changes.
Name-based virtual hosting allows multiple DNS hostnames to be hosted by a single server (usually a web server) on the same IP address. To achieve this the server uses a hostname presented by the client as part of the protocol (for HTTP the name is presented in the host header). However when using HTTPS the TLS handshake happens before the server sees any HTTP headers. Therefore it is not possible for the server to use the information in the HTTP host header to decide which certificate to present and as such only names covered by the same certificate can be served from the same IP address.
In practice, this means that an HTTPS server can only serve one domain (or small group of domains) per IP address for secured browsing. Assigning a separate IP address for each site increases the cost of hosting, since requests for IP addresses must be justified to the regional internet registry and IPv4 addresses are now in short supply. The result is that many websites are effectively prevented from using secure communications over IPv4. IPv6 naturally deals in blocks of IP addresses at a time so is unaffected by this issue.
How SNI fixes the problem
SNI addresses this issue by having the client send the name of the virtual domain as part of the TLS negotiation. This enables the server to select the correct virtual domain early and present the browser with the certificate containing the correct name. Therefore with clients and servers that implement SNI, a server with a single IP address can serve a group of domain names for which it is impractical to get a common certificate.
In 2004, a patch for adding TLS/SNI into OpenSSL was created by the EdelKey project. In 2006, this patch was then ported to the development branch of OpenSSL, and in 2007 it was back-ported to OpenSSL 0.9.8.
For an application program to implement SNI, the TLS library it uses must implement it and the application must pass the hostname to the TLS library. Further complicating matters, the TLS library may either be included in the application program or be a component of the underlying operating system. Because of this, some browsers implement SNI when running on any operating system, while others implement it only when running on certain operating systems.
- Internet Explorer 7 or later, on Windows Vista or higher. Not in any Internet Explorer version on Windows XP or Windows Server 2003 because SNI depends upon the SChannel system component shipped with Windows Vista.
- Mozilla Firefox 2.0 or later
- Opera 8.0 (2005) or later (the TLS 1.1 protocol must be enabled)
- Opera Mobile at least version 10.1 beta on Android
- Google Chrome (Vista or higher. XP on Chrome 6 or newer OS X 10.5.7 or higher on Chrome 5.0.342.1 or newer)
- Safari 3.0 or later (Mac OS X 10.5.6 or higher and Windows Vista or higher)
- Konqueror/KDE 4.7 or later 
- MobileSafari in Apple iOS 4.0 or later
- Android default browser on Honeycomb (v3.x) or newer
- BlackBerry 10 and BlackBerry Tablet OS default browser
- Windows Phone 7 or later
- MicroB on Maemo
- Odyssey on MorphOS
- Apache 2.2.12 or later using mod_ssl or alternatively with mod_gnutls
- Microsoft Internet Information Server IIS 8 or later.
- Nginx with an accompanying OpenSSL built with SNI capability
- Apache Traffic Server 3.2.0 or later.
- Radware Alteon ADC
- A10 Networks Thunder ADC 2.7.2 or later
- Cherokee if compiled with TLS capability
- Versions of lighttpd 1.4.x and 1.5.x with patch, or 1.4.24+ without patch
- F5 Networks Local Traffic Manager running version 11.1 or later 
- Ping Access 3.0 or later
- Hiawatha (web server) 8.6 or later
- LiteSpeed 4.1 or later
- Pound 2.6 or later
- PageKite tunneling reverse proxy
- Saetta Web Server via OpenSSL
- LBL®LoadBalancer 9.1 or later
- Citrix NetScaler 9.2 or later (9.3 Enhanced)
- Radware Alteon ADC running AlteonOS 28.1 or later 
- HAProxy 1.5 or later 
- EVO Mail Server 
- Fortinet FortiWeb WAF 5.3 or later 
- Mozilla NSS 3.11.1 client-side only
- 0.9.8f (released 11 Oct 2007) - not compiled in by default, can be compiled in with config option '--enable-tlsext'.
- 0.9.8j (released 07 Jan 2009) through 1.0.0 (released 29 March 2010) - compiled in by default
- wolfSSL (previously CyaSSL) - not compiled in by default, can be compiled in with config option '--enable-sni' or '--enable-tlsx'.
- mbed TLS (previously PolarSSL) since 1.2.0 - compiled in by default
- libcurl / cURL since 7.18.1 (released 30 Mar 2008) when compiled against an SSL/TLS toolkit with SNI
- Python 2.7.9, 3.2 and above (
- Qt 4.8
- Oracle Java 7 JSSE 
- Apache HttpComponents 4.3.2 
- wget 1.14
- Android 2.3 (Gingerbread) has partial support if application uses HttpsURLConnection class.
- Android 4.2 (Jellybean MR1) exposes SNI support on raw sockets via its SSLCertificateSocketFactory class.
- IO::Socket::SSL (Perl/CPAN module, since version 1.83 )
- Pike 7.9.5 (SSL module) 
- MatrixSSL (client and server)
- stunnel (client and server)
- Go (client and server)
The following combinations do not implement SNI:
- WebClient service (for WebDAV) included in any Windows version
- Internet Explorer 6 or earlier and any IE version on Windows XP or earlier
- Safari on Windows XP or earlier
- BlackBerry OS 7.1 or earlier
- Windows Mobile up to 6.5
- Android default browser on Android 2.x (Fixed in Honeycomb for tablets and Ice Cream Sandwich for phones)
- wget before 1.14
- Nokia Browser for Symbian at least on Series60
- Opera Mobile for Symbian at least on Series60
- SAP (according to some consultants)
- Qt client side up to 4.7
- Mozilla NSS server side 
- Java before 1.7
- Python 2.x (except 2.7.9), 3.0, 3.1 (
- "Server Name Indication". Transport Layer Security (TLS) Extensions. IETF. p. 8. sec. 3.1. RFC 3546. https://tools.ietf.org/html/rfc3546#section-3.1.
- "CAcert VHostTaskForce". CAcert Wik.
- "What is a Multiple Domain (UCC) SSL Certificate?".
- "TLS Server Name Indication". Paul's Journal.
- "EdelKey Project".
- Brand, Kaspar (2009-03-29). "TLS SNI Test Site".
- Opera (2005-02-25). "Changelog for Opera  Beta 2 for Windows" (via Archive.org). Opera Changelogs for Windows. Opera.com. Archived from the original on 2005-11-23.
Readded experimental support for TLS Extensions and TLS 1.1. Setting is disabled by default.
- "Google Chrome, Issue 43142, Use SSLClientSocketNSS on Windows by default". 2010-10-29.
- "Bug 122433: Server Name Identification support". Bugs.kde.org. Retrieved 2011-07-18.
- Kehrer, Paul. "SNI in iOS 4.0". Retrieved 22 November 2010.
- "Issue 12908 - android Https - websites that support Server Name Indication (SNI) don't work". code.google.com. Retrieved 23 August 2011.
- "Bug 34607: Support for Server Name Indication". Apache Software Foundation.
- "Revision 776281: adding support for Server Name Indication to the Apache 2.2.x branch". Apache Software Foundation.
- "CHANGES: Server Name Indication support is listed under the changes for Apache 2.2.12". Apache Software Foundation.
- Notaras, George (2007-08-10). "SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls".
- "What’s New in IIS 8". weblogs.asp.net. Retrieved 2012-04-01.
- "#386 (TLS servername extension (SNI) for namebased TLS-vhosts)". Trac.lighttpd.net. Retrieved 2011-03-08.
- "1.4.24 - now with TLS SNI and money back guarantee". Blog.lighttpd.net. Retrieved 2011-03-08.
- "sol13452: Configuring a virtual server to serve multiple HTTPS sites using TLS Server Name Indication (SNI) feature". ask.f5.com. Retrieved 2012-03-26.
- "Apsis Gmbh". apsis.ch. Retrieved 2011-08-18.
- "Open Source PageKite". PageKite.net. Retrieved 2012-04-18.
- "SSL/TLS back-ends, endpoints and SNI". PageKite.net. Retrieved 2012-04-18.
- Features of Saetta web server
- "Unified Reverse Proxy". TCOGROUP.
- "Configuring an SSL Virtual Server for Secure Hosting of Multiple Sites". Citrix. Retrieved 5 July 2012.
- "Introducing AlteonOS 28.1! - Knowledge Base - Radware". kb.radware.com. Retrieved 2012-08-20.
- "HAProxy - The Reliable, High Performance TCP/HTTP Load Balancer".
- "EVO Mail Server with TLS SNI support".
- "FortiWeb 5.3.0 CLI Reference - server certificate sni". http://docs.fortinet.com/d/fortiweb-5-3-0-cli-html. Retrieved 2015-01-02.
- "NSS 3.11.1 Release Notes". Mozilla.org. Retrieved 2011-03-08.
- "TLS Extensions". Gnu.org. 2010-08-01. Retrieved 2011-03-08.
- "Using Server Name Indication (SNI) with CyaSSL". wolfSSL.com. 2013-05-24. Retrieved 2013-11-25.
- "Support TLS SNI extension in ssl module". Bugs.python.org. Retrieved 2011-03-08.
- "QTBUG-1352. It would be useful if QSslSocket supports TLS extensions such as Server Name Indication as per RFC 3546.". Qt Bug Tracker. Retrieved 2011-04-15.
- "Java SE 7 Release Security Enhancements". download.oracle.com. Retrieved 2012-12-12.
- "HttpComponents HttpClient 4.3.2 Released". Retrieved 2014-01-21.
- "News: GNU wget 1.14 released". GNU Wget. 2012-10-19.
- "Android’s HTTP Clients". Google. Retrieved 3 August 2012.
- "SSLCertificateSocketFactory | Android Developers". Google. Retrieved 9 January 2015.
- "IO::Socket::SSL Changes file mentions introduction of SNI".
- "Pike's SSL module". Retrieved 30 August 2013.
- "MatrixSSL news page".
- "stunnel man page".
- "Go TLS package".
- "Understanding Certificate Name Mismatches". Blogs.msdn.com. Retrieved 2011-03-08.
- "Android issue 1290 - Https websites that support Server Name Indication (SNI) don't work". Code.google.com. 2010-12-01. Retrieved 2011-12-13.
- "IBM HTTP Server SSL Questions and Answers". Publib.boulder.ibm.com. Retrieved 2011-03-08.
- "IHS 8 powered by Apache 2.2.x ?". Publib.boulder.ibm.com. Retrieved 2011-03-08.
- "Stack Overflow post by a Tomcat Comitter". http://stackoverflow.com/questions/20190464/howto-setup-tomcat-serving-two-ssl-certificates-using-sni.
- "NSS Roadmap (as of 11 September 2009)". Wiki.mozilla.org. Retrieved 2011-03-08.
- "Implement TLS Server Name Indication for servers". Bugzilla@Mozilla. 2006-11-11. Retrieved 2012-10-30.
- RFC 6066 (obsoletes RFC 4366 (which obsoleted RFC 3546))
- https://alice.sni.velox.ch/ Test client-side TLS SNI capability
- Server Name Indication (SNI) with IIS 8 (Windows Server 2012) - Unleashed - Site Home - MSDN Blogs