早期的SSLv2根據經典的公鑰基礎設施PKI(Public Key Infrastructure)設計，它默認認為：一台服務器（或者說一個IP）只會提供一個服務，所以在SSL握手時，服務器端可以確信客戶端申請的是哪張證書。
但是讓人萬萬沒有想到的是，虛擬主機大力發展起來了，這就造成了一個IP會對應多個域名的情況。解決辦法有一些，例如申請泛域名證書，對所有*.yourdomain.com的域名都可以認證，但如果你還有一個yourdomain.net的域名，那就不行了。
在HTTP協議中，請求的域名作為主機頭（Host）放在HTTP Header中，所以服務器端知道應該把請求引向哪個域名，但是早期的SSL做不到這一點，因為在SSL握手的過程中，根本不會有Host的信息，所以服務器端通常返回的是配置中的第一個可用證書。因而一些較老的環境，可能會產生多域名分別配好了證書，但返回的始終是同一個。
根據HTTPS的工作原理，瀏覽器在訪問一個HTTPS站點時，先與服務器建立SSL連接，建立連接的第一步就是請求服務器的證書。而服務器在發送證書的時候，是不知道瀏覽器訪問的是哪個域名的，所以不能根據不同域名發送不同的證書。
既然問題的原因是在SSL握手時缺少主機頭信息，那么補上就是了。
SNI（Server Name Indication）是為了解決一個服務器使用多個域名和證書的SSL/TLS擴展。定義在RFC 4366。是一項用於改善SSL/TLS的技術，在SSLv3/TLSv1中被啟用。它允許客戶端在發起SSL握手請求時（具體說來，是客戶端發出SSL請求中的ClientHello階段），就提交請求的Host信息，使得服務器能夠切換到正確的域並返回相應的證書。一句話簡述它的工作原理就是，在連接到服務器建立SSL鏈接之前先發送要訪問站點的域名（Hostname），這樣服務器根據這個域名返回一個合適的證書。目前，大多數操作系統和瀏覽器都已經很好地支持SNI擴展，OpenSSL 0.9.8已經內置這一功能，據說新版的nginx也支持SNI。
要使用SNI，需要客戶端和服務器端同時滿足條件，幸好對於現代瀏覽器來說，大部分都支持SSLv3/TLSv1，所以都可以享受SNI帶來的便利。
用代碼來演示:
server {
listen 443; server_name www.example.com; ssl on; ssl_certificate www.example.com.crt; ... } server { listen 443; server_name www.example.org; ssl on; ssl_certificate www.example.org.crt; ... }
使用上面的配置，不論瀏覽器請求哪個主機，都只會收到默認主機www.example.com的證書。這是由SSL協議本身的行為引起的——先建立SSL連接，再發送HTTP請求，所以nginx建立SSL連接時不知道所請求主機的名字，因此，它只會返回默認主機的證書。
最古老的也是最穩定的解決方法就是每個HTTPS主機使用不同的IP地址：
server { listen 192.168.1.1:443; server_name www.example.com; ssl on; ssl_certificate www.example.com.crt; ... } server { listen 192.168.1.2:443; server_name www.example.org; ssl on; ssl_certificate www.example.org.crt; ... }
那么，在同一個IP上，如何配置多個HTTPS主機呢？
nginx支持TLS協議的SNI擴展。不過，SNI擴展還必須有客戶端的支持，另外本地的OpenSSL必須支持它。
如果啟用了SSL支持，nginx便會自動識別OpenSSL並啟用SNI。是否啟用SNI支持，是在編譯時由當時的 ssl.h 決定的（SSL_CTRL_SET_TLSEXT_HOSTNAME），如果編譯時使用的OpenSSL庫支持SNI，則目標系統的OpenSSL庫只要支持它就可以正常使用SNI了。
nginx在默認情況下是TLS SNI support disabled。如果需要支持，編譯時需要增加:
--with-http_ssl_module \ --with-openssl=./openssl-1.0.1e \ --with-openssl-opt="enable-tlsext"
但是我用的nginx/1.10.1，在編譯時沒有添加--with-open-opt="enable-tlsext"，就可以支持SNI了，所以最新版本默認是開啟的？