| 四层 | 七层 | |
| 浏览器（客户端） |
dns解析 connect ip 在clientHello中用浏览器地址栏host塞入sni |
在http头中塞入Host头 |
| 网关（服务端） | 根据SNI路由 |
根据Host头路由 |
|
hauqi，openshift根据SNI路由passthrough的tcp流量 所以openshift必然会通过某种方式，获取host来路由，这也从性质上决定了我不能侵入sni 所以它只可以通过域名访问而不能通过ip 应用1：app1.host/app1/ 应用2：app2.host/app2/ app1.host ip === app2.host ip 然后openshift就通过sni拿到了host ，无论客户端是浏览器或java或curl |
jiutou，nginx负责统一证书和ssl解码，根据浏览器域名路由到不同tomcat实例 缺点是无法双向ssl |
|
| 浏览器验证 |
如果作为反向代理，由各应用端自己返回 如果仅是多域名多证书同ip情况，则有服务器框架根据sni选取证书 |
nginx给唯一域名的证书就行 |
参考：
https://blog.csdn.net/chen1415886044/article/details/116330304
该扩展使得可以在TLS握手期间指定网站的主机名或域名 ，而不是在握手之后打开HTTP连接时指定。
SNI通过让客户端发送虚拟域的名称作为TLS协商的ClientHello消息的一部分来解决此问题。这使服务器可以及早选择正确的虚拟域，并向浏览器提供包含正确名称的证书。
服务器名称指示（SNI）有效负载未加密，因此客户端尝试连接的服务器的主机名对于被动的窃听者是可见的。
Web服务器通常负责多个主机名–或域名。如果网站使用HTTPS 则每个主机名将具有其自己的SSL证书。
在HTTPS中，先有TLS握手，然后才能开始HTTP对话。如果没有SNI，客户端将无法向服务器指示正在与之通信的主机名。
如果服务器可能为错误的主机名生成SSL证书。那么SSL证书上的名称与客户端尝试访问的名称不匹配，则客户端浏览器将返回错误信息，并通常会终止连接。
通过 SNI，拥有多虚拟机主机和多域名的服务器就可以正常建立 TLS 连接了。
https://blog.csdn.net/qq_21127151/article/details/107032419
在HTTP协议中，请求的域名作为主机头（Host）放在HTTP Header中，所以服务器端知道应该把请求引向哪个域名，但是早期的SSL做不到这一点，因为在SSL握手的过程中，根本不会有Host的信息，所以服务器端通常返回的是配置中的第一个可用证书。因而一些较老的环境，可能会产生多域名分别配好了证书，但返回的始终是同一个。
在SSLv3/TLSv1中被启用
所以nginx建立SSL连接时不知道所请求主机的名字，因此，它只会返回默认主机的证书。
nginx支持TLS协议的SNI扩展（Server Name Indication，不过，SNI扩展还必须有客户端的支持，另外本地的OpenSSL必须支持它。 如果启用了SSL支持，nginx便会自动识别OpenSSL并启用SNI。是否启用SNI支持，是在编译时由当时的 ssl.h 决定的（SSL_CTRL_SET_TLSEXT_HOSTNAME），如果编译时使用的OpenSSL库支持SNI，则目标系统的OpenSSL库只要支持它就可以正常使用SNI了。 nginx在默认情况下是TLS SNI support disabled，需要重新编译nginx并启用TLS。启用方法步骤如下：
https://help.yunaq.com/faq/5256/index.html
浏览器在访问使用HTTPS协议的站点时，需与服务器建立SSL连接，建立连接的第一步是请求域名证书，此时如服务器部署了多个证书，因客户端还未发送实际的数据请求，服务器无法区分请求的域名
大多数操作系统和浏览器都已经很好地支持SNI扩展，OpenSSL 0.9.8已内置这一功能，新版的Nginx也已支持SNI
标签：tomcat,证书,SNI,SSL,域名,白名单,服务器,客户端 From： https://www.cnblogs.com/silyvin/p/18047571