SNI扩展：同一IP配置多个HTTPS主机

早期的SSL2.0根据经典的公钥基础设施PKI(PublicKey Infrastructure)设计，它默认认为：一台服务器（或者说一个IP）只会提供一个服务，所以在SSL握手时，服务器端可以确信客户端申请的是哪张证书。

但是让人万万没有想到的是，虚拟主机大力发展起来了，这就造成了一个IP会对应多个域名的情况。有一些解决办法，例如申请通配域名证书，对所有同一顶级域名下的二级子域名（*.yourdomain.com）都可以认证，但如果你还有一个yourdomain.net的域名，那就不行了。

在HTTP协议中，请求的域名作为主机头（Host）放在HTTP Header中，所以服务器端知道应该把请求引向哪个域名，但是早期的SSL做不到这一点，因为在SSL握手的过程中，根本不会有Host的信息，所以服务器端通常返回的是配置d中的第一个可用证书。因而一些较老的环境，可能会产生多域名分别配好了证书，但返回的始终是同一个。

既然问题的原因是在SSL握手时缺少主机头信息，那么补上就是了。

SNI解决了什么问题

SNI（Server Name Indication）定义在RFC 4366，是一项用于改善SSL/TLS的技术，在SSL3.0/TLS1.0中被启用。它允许客户端在发起SSL握手请求时（具体说来，是客户端发出SSL请求中的ClientHello阶段），通过SNI扩展，将域名信息提前告诉服务器，服务器根据域名取得对应的证书返回给客户端，以完成校验过程。

要使用SNI，需要客户端和服务器端同时满足条件，幸好对于现代浏览器来说，大部分都支持SSL3.0/TLS1.0及以上版本，所以都可以享受SNI带来的便利。

Nginx应用实例

比如：公司域名变更，又要新旧域名同时运行。以Ngnix为例，如果在同一个IP上配置多个HTTPS主机，会出现一个很普遍的问题：不论浏览器请求哪个主机，都只会收到默认主机www.example.com的证书。这是由SSL协议引起的——先建立SSL连接，再发送HTTP请求，所以nginx建立SSL连接时不知道所请求主机的名字，因此，它只会返回默认主机的证书。

最古老的也是最稳定的解决方法就是每个HTTPS主机使用不同的IP地址：

那么，在同一个IP上，如何配置多个HTTPS主机呢？

Nginx支持TLS协议的SNI扩展，不过SNI扩展还必须有客户端的支持，另外本地的OpenSSL必须支持它。如果启用了SSL支持，nginx便会自动识别OpenSSL并启用SNI。是否启用SNI支持，是在编译时由当时的 ssl.h 决定的，如果编译时使用的OpenSSL库支持SNI，则目标系统的OpenSSL库只要支持它就可以正常使用SNI了。

nginx在默认情况下是TLS SNIsupport disabled，需要重新编译nginx并启用TLS。步骤如下：

查看是否启用：

这样就可以在同一个IP上配置多个HTTPS主机了。实例如下：

这样访问每个虚拟主机都正常。