前沿
据悉苹果强制APP在2016年底使用ATS协议，所以公司准备将部分站点http统一替换成https。所有我们就得测试下
1.首先原有的haproxy1.5升级到了1.7版本支持ssl
2.查看相关文档，测试
3.如果站点经过CDN加速，还需要确认CDN是否支持https或者支持是否收取额外费用
4.等等。。。。。。
1.现有环境
2.haproxy代理ssl模式
haproxy 代理 ssl 有两种方式
1、haproxy 本身提供ssl 证书，后面的web 服务器走正常的http （偷懒方式）
2、haproxy 本身只提供代理，后面的web服务器https
- 第一种是我们选择的模式，在haproxy这里设定SSL，这样我们可以继续使用七层负载均衡。SSL连接终止在负载均衡器haproxy ----->解码SSL连接并发送非加密连接到后端应用tomcat，这意味着负载均衡器负责解码SSL连接，这与SSL穿透相反，它是直接向代理服务器发送SSL连接的。
- 第二种使用SSL穿透，SSL连接在每个tomcat服务器终止，将CPU负载都分散到tomcat服务器。然而，这样做会让你失去增加或修改HTTP报头的能力，因为连接只是简单地从负载均衡器路由到tomcat服务器，这意味着应用服务器会失去获取 X-Forwarded-* 报头的能力，这个报头包含了客户端IP地址、端口和使用的协议。
- 有两种策略的组合做法，那就是第三种，SSL连接在负载均衡器处终止，按需求调整，然后作为新的SSL连接代理到后台服务器。这可能会提供最大的安全性和发送客户端信息的能力。这样做的代价是更多的CPU能耗和稍复杂一点的配置。
- 选择哪个策略取决于你及应用的需求。SSL终端为我所见过最典型的策略，但SSL穿透可能会更安全。
ps:这段是招扒的wangzan18的。在此谢谢
第一种方式
需要编译haproxy 支持ssl，编译参数：
make TARGET=linux26 USE_OPENSSL=1 ADDLIB=-lz
ldd haproxy | grep ssl
libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007fb0485e5000)配置参数：
frontend https_frontend
bind *:443 ssl crt /etc/ssl/certs/servername.pem
mode http
option httpclose
option forwardfor
reqadd X-Forwarded-Proto:\ https
default_backend web_server
backend web_server
mode http
balance roundrobin
cookie SERVERID insert indirect nocache
server s1 192.168.250.47:80 check cookie s1
server s2 192.168.250.49:80 check cookie s2
注意：这里的pem 文件是下面两个文件合并而成：
cat servername.crt servername.key |tee servername.pem
第二种方式配置
不需要重新编译支持ssl，简单方便。需要后面的web服务器配置好ssl 即可。
frontend https_frontend
bind *:443
mode tcp
default_backend web_server
backend web_server
mode tcp
balance roundrobin
stick-table type ip size 200k expire 30m
stick on src
server s1 192.168.250.47:443
server s2 192.168.250.49:443
注意：这种模式下mode 必须是tcp 模式
3.配置说明
这一行要加，要不然reload会警告
tune.ssl.default-dh-param 2048
保留80，同时支持443 ssl,后面指定证书文件
redirect scheme https if !{ ssl_fc }
这一行是仅支持ssl,效果是：访问80端口是自动跳转到443的ssl
这是针对node生效，如果想全局使用的话，可以把这句话添加到frontend下
这是针对node生效，如果想全局使用的话，可以把这句话添加到frontend下
我们只需要努力，然后剩下的交给时间。
