背景介绍：2017年1月份，Google将Chrome 56中所有的 http站点标记为不安全，并对所有使用http方式的登录交互页发出醒目的“不安全”提示。
Apple自2015年WWDC大会开始，就在计划逐步推进实施ATS(App与后台服务器通讯强制使用https通讯)的实施，并在2017年WWDC大会上发布明确的时间节点，使https服务成为所有iOS及MAC上App的标配。
随着一些国际主流CA机构免费型DV SSL证书产品的出现，SSL/TLS证书的应用越来越广泛。SSL证书与域名一样，很快会成为每一个互联网站点不可或缺的基础服务要素。SSL/TLS证书的应用逐渐普及，越来越多的站点正在加速启用全站https服务。而在浏览器方面，Chrome及Firefox在所有新发布的浏览器版本中支持HSTS。已经有相当一部分站点启用了HSTS服务，彻底将http服务从支持的选项列表中移除。
如何保障SSL/TLS证书的安全及可靠？
全面的推广和应用SSL/TLS，会给站点安全性带来质的提升，彻底杜绝中间人攻击、网络劫持等攻击行为。但于此同时，考虑全站https之后的高可用保障时，SSL/TLS证书的安全性问题就逐步凸显出来。
如何确保https服务能够7*24不间断服务，不仅是企业内部IT运营团队需要考虑的问题，同时也对第三方CA服务商提出了更高的要求。
一旦第三方CA服务商出现运营或安全事故，将导致CA服务商的认证服务不可用。这将直接影响到使用企业IT服务的最终用户。无论是PC客户端浏、移动终端，还是API接口程序，都将有可能因此受到冲击，导致服务不可用。
因此在进行站点高保障安全运营维护工作的同时，要求SSL/TLS服务供应商也必须确保提供7*24不间断的高可用性服务，才能保障服务的可靠性。
SSL/TLS证书服务需注意这三点：
比起单纯的采用一张SSL/TLS证书，要确保高可用性保障的服务站点不受一家第三方CA认证机构的安全或运营事故牵连，同时使用两家不同的CA机构提供的高可用性SSL/TLS证书服务就显得尤为必要了。
无论是选择一张SSL/TLS证书服务，还是采用双证书方案同时使用两张SSL/TLS证书，都需要首先考察CA服务机构在服务保障上的工作是否有做足功课。
首先，CA机构在体量上，当然是越大越好。选择全球排名靠前的几家大型老牌CA机构的产品，能够确保CA机构的产品有更深厚的技术积累和安全保障。不会因为黑客组织或个人的攻击行为、系统安全系统漏洞、认证不规范等各种原因导致服务中断或被其他机构列入信任黑名单。
其次，CA服务商在此之前是否发生过大的安全或运营事故，是否遭受过严厉惩罚措施也是需要预先考察的。在事故发生后，CA服务商能否协调各方快速及时处理，并保障最小限度的影响客户的这种能力，也会给客户的证书应用保障加分。
最后，CA服务商在国内是否有服务加速。
证书签发后，在证书的使用过程中，通常还需要客户端请求CA系统获取证书有效性验证信息。证书的有效性验证，主要采用两种方式：OCSP及CRL。
OCSP的验证数据包体积较小，但对应答的及时性有要求。服务器延时越小，客户端验证速度越快。
CRL的验证数据包体积较大，但支持CRL支持缓存。可通过CA服务商的CDN加速服务网络分发。因此要求CA服务商在国内使用CDN加速服务也是很有必要的。
以下方案，主证书采用Digicert（原Symantec）品牌，备份证书采用Entrust或GlobalSign品牌。
如何部署实施高可用性双证书？
1.单证书在线
单证书在线方案实施起来非常简单，也很好理解其运行模式。主证书部署在服务器上，备份证书在主证书正常运行期间并不需要安装部署。一旦发生CA服务商安全或运营事故的情况，可通过手动更新配置启用备份证书并下线主证书，或通过自动化部署脚本自动切换到备份证书服务上。
主证书可按照应用需求，购买单域名、增强验证型带绿色地址栏的EV型、多域名或通配符等类型的证书。主证书的注册申请、维护和安装仍然使用原有的模式，不改变部署安装习惯。
备份证书推荐采用多域名，或通配符证书。只需要确保备份证书能够快速覆盖主证书的服务范围，通常不需要频繁的变更或重新注册申请。并且在需要应急启用时，能够快速变更替换主证书对应的服务。
2.源站服务器使用主证书，CDN、高防、WAF等服务使用备份证书
使用CDN、高防或WAF服务的用户，可在源站服务器上安装使用主证书，在CDN、高防、WAF等服务中使用备证书。
通常这类服务还可能委托给第三方CDN服务商来部署实施，所以这种模式下使用双证书方案时，选择两个不同的CA服务商提供的产品不仅能够规避CA运营或安全封信问题，同时源站与CDN、高防、WAF服务上配置的证书使用的证书密钥对也是不同的。任何一个证书出现的运营安全故障（如秘钥丢失、秘钥泄密）都可以快速定位责任主体。第三方CDN服务商的秘钥泄露也不会影响到源站的数据传输安全。
3.主备证书同时在线
成功案例解析
由于Chrome的bug导致所有2016年6月1号之后签发的证书，在Chrome 53、54下报证书透明度日志不可用错误（CT Log），某互联网头部企业启用了
Digicert（原Symantec）+ GlobalSign 双证书方案。针对IE、Firefox等浏览器，自动使用Digicert（原Symantec）证书，所有版本的Chrome浏览器访问，则自动启用GlobalSign证书。
一些超大型网站或应用，往往对SSL/TLS证书的兼容性有着非常严苛的要求，部分通过API接口对接的服务型产品，更对CA服务商的产品有着更高的兼容性要求。主证书使用大牌CA厂商的证书产品，往往能够获得最优的兼容性支持。但当遇到特定应用场景下的不兼容时，使用双证书应用解决方案，可以有效的规避超大型站点在客户端出现的SSL/TLS证书兼容性故障，同时确保API接入用户不会受到证书变更造成的不良影响。
通常，使用双证书同时在线的方案，需要使用到前端代理服务器通过http代理，UserAgent的识别，Proxy的https重定向来实现这一目标。
以下以Nginx的代理配置来简单介绍：AI 代码解读
要实现根据用户 UA，自动重定向到策略指定的SSL/TLS证书服务站点上，首先要求后端必须有多台服务器负责处理https请求，并且在这些站点中分别部署主备两张不同的证书。其次，站点必须关闭HSTS，以避免客户端浏览器直接通过https方式访问服务器。用户必须是以默认的http服务访问服务器，然后由服务端的Proxy代理进行策略负载。
其配置原理如下：
if ( condition ){
do_something
}
if ( $http_user_agent = "wget" ){
do_something
}
if ( $http_user_agent ~ MSIE ){
do_something else;
}
AI 代码解读
首先，配置好后端服务器策略，为不同的服务器群集配置其专用的证书
######配置IE浏览器后台服务器群集，并在群集服务器上配置Symantec证书
upstream msiebackend {
server 192.168.1.1;
server 192.168.1.2;
server 192.168.1.3;
}
######配置Chrome浏览器后台服务器群集，并在群集服务器上配置GlobalSign证书
upstream chromebackend {
server 192.168.1.4;
server 192.168.1.5;
server 192.168.1.6;
}
######配置Firefox浏览器后台服务器群集，并在群集服务器上配置Symantec或其他证书
upstream mozillabackend {
server 192.168.1.7;
server 192.168.1.8;
server 192.168.1.9;
}
AI 代码解读
最后，配置Porxy策略，将不同User Agent标识的客户端浏览器导向到特定的后台服务器上。示例如下：
server {
access_log logs/access.log;
error_log logs/error.log;
listen 80 default;
server_name baidu.com www.baidu.com; ## 代理转发站点的域名
location / {
proxy_pass https://msiebackend; ## 默认使用Symantec证书
if ($http_user_agent ~ Chrome ) {
proxy_pass https://chromebackend; ## 为Chrome浏览器启用GlobalSign证书
}
if ($http_user_agent ~ Mozilla ) {
proxy_pass https://mozillabackend; ## 为Firefox 浏览器启用Symantec或其他证书
}
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
...s
}
AI 代码解读
完成以上配置后，重启Nginx，用不同浏览器客户端尝试访问您的站点，测试证书的部署策略是否生效。
如果再深入细致的对User Agent进行策略定制，将可以更细致的控制客户端的访问代理。
END
