A presentation
earlier SSLv2 According to the classical Public Key Infrastructure PKI (Public Key Infrastructure) design, it defaults to that: a server (or a IP) will only provide a service, so the handshake in SSL, the server can be sure the client application which certificates. But people never imagined that web hosting vigorously developed, which resulted in a situation of multiple domain names corresponding to IP will. There are some solutions, such as apply for pan-domain certificate for all * .yourdomain.com domain can be authenticated, but if you have a yourdomain.net domain name, it is not. In the HTTP protocol, the requested domain name on the head as the host (Host) HTTP Header in, so the server knows which domain should be directed to the request, but early SSL can not do this, because the SSL handshake process, the Host will not have the information, so the server normally returns the first available certificate configuration. Thus some of the older environment, could produce multi-domain certificates are a good job, but the return is always the same. Since the cause of the problem is the lack of host header information in the SSL handshake, then fill it wants. SNI (Server Name Indication) is defined in RFC 4366, is a technique for improving the SSL TLS /, is enabled SSLv3 / TLSv1 in. It allows the client when initiating the SSL handshake request (specifically, a client sends a request ClientHello phase SSL), Host information request submitted so that the server can be switched to the correct domain and returns the corresponding certificate. [warning]
to use the SNI, requires the client and the server at the same time to meet the conditions
, but fortunately for modern browsers, most support SSLv3 / TLSv1, so you can enjoy the convenience brought by SNI. [/ warning]
. two nginx / apache server-side implementation
nginx and apache server supports SNI See also:
"Nginx configure multiple HTTPS hosts on the same IP"
"the Apache mod_gnutls multi HTTPS virtual host"
III. SNI supported browser, server, libraries,
Internet Explorer 7 or later, on Windows Vista or higher. Does not work on Windows XP , even 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 [citation needed] 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 2.1 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 or newer Windows Phone 7 [citation needed] MicroB on Maemo
IV. the server supports SNI Apache 2.2.12 or later using mod_ssl(or alternatively with experimental mod_gnutls) Cherokee if compiled with TLS support Versions of lighttpd 1.4.x and 1.5.x with patch, or 1.4.24+ without patch Nginx with an accompanying OpenSSL built with SNI support LiteSpeed 4.1 or later Pound 2.6 or later Apache Tomcat on Java 7 or later Microsoft Internet Information Server IIS 8
五. 支持SNI的库 Mozilla NSS 3.11.1 client-side only OpenSSL 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 GNU TLS libcurl / cURL since 7.18.1 (released 30 Mar 2008) when compiled against an SSL/TLS toolkit with SNI support Python 3.2 (ssl, urllib and httplib modules) Qt 4.8 Oracle Java 7 JSSE 参考文档：http://blog.hesey.net/2012/02/sni-for-multi-domain-ssl-tls.html http://serverfault.com/questions/109800/multiple-ssl-domains-on-the-same-ip-address-and-same-port
Reproduced in: https: //my.oschina.net/766/blog/211504