背景

之前在替换到期的服务器ssl证书时发现HTTPS站点进行业务访问时，WINDOWS XP客户端IE浏览器获取到的ssl证书和网站证书不一致问题，经排查问题是WAF的证书管理机制适配性造成。公司使用的某厂waf证书管理机制实现原理为WAF的证书管理做了一个证书池机制，有且只有一个证书池。一台WAF的所有证书都在这个证书池内，每次证书交互都存在一定几率返回证书错误的现象。一直到新版本补丁新增SNI功能支持，依托SNI功能实现证书和https站点的绑定关系。但是存在一个缺陷，当客户端不支持SNI功能的时候，还会存在证书交互错误的现象。

总得来说sni机制还是属于特定条件下遇到的一个坑（windows xp,android4.3以下的系统）,如果由于客户终端环境遇到访问https业务异常的时候，可作为一个可选排查项。接下来本文讲一下sni机制。

工作原理

waf反向代理模式，用nginx作为前端负载均衡器并负责https集中解密工作(以用户访问的域名为依据进行流量分配，同样的也是以域名为依据来判断应该将哪张证书丢给用户。即：SNI(Server Name Identification)功能

1、用户通过DNS解析获知"a.test.com"、"b.test.com"、"c.test.com"三个域名对应的IP都为"192.168.178.154"

2、用户与"192.168.178.154"进行SSL握手，获取相应域名证书后再次向"192.168.178.154"发起真正的http(已加密)请求

3、"192.168.178.154"收到加密后的http请求后先进行解密，然后再根据相应的策略向后端服务器server1-3发起http请求(未加密)

4、后端服务器server1-3进行处理后将回应的包发送给nginx，nginx将该数据进行加密后再次封装然后发送给用户

以上流程xp在访问http站点时，一切正常，但到了https站点的情况，则有所不同：

xp在进行ssl握手时，第一次使用TLSv1握手失败，然后自动换用SSLv3进行握手，但依然失败。

尝试用win7访问https站点，发现可以成功，比较两者：

可以看到WIN7的hello包中携带了Extension:server_name字段，并且里面包含了要访问的域名信息。而反观WINXP则没有该字段，所以WIN7发hello的时候的nginx就会回应hello，而WINXP发hello时nginx就会回Alert。

所以结论就很明显了，WINXP在使用IE访问https网站时，服务器不能使用SNI方式进行分流，不然会因为不能建立SSL握手而访问失败。

解决方案

那么windows xp如何访问https站点呢，以下为使用搜狗浏览器抓的包。

搜狗浏览器在发送SSL的hello包时会携带Extension:server_name字段。

可以发现换浏览器是可以解决这一问题，但是作为服务器方的我们是不能要求客户的浏览器，那么服务器方面有什么解决方案呢？有的，主要是两种：

1、服务端通过IP地址颁发证书（WINXP虽不携带访问的域名信息，但它总有三层包头吧！

2、服务端全站只用一张大通配证书，无论用户访问哪个域名都将该证书丢给它。