如何解决SSL/ TLS证书服务的高可用性?-阿里云开发者社区

开发者社区> 开发与运维> 正文
登录阅读全文

如何解决SSL/ TLS证书服务的高可用性?

简介: 如何解决SSL/ TLS证书服务的高可用性? 全面的推广和应用SSL/TLS,会给站点安全性带来质的提升,彻底杜绝中间人攻击、网络劫持等攻击行为。但于此同时,考虑全站https之后的高可用保障时,SSL/TLS证书的安全性问题就逐步凸显出来。

背景介绍: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的代理配置来简单介绍:

要实现根据用户 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;
}

首先,配置好后端服务器策略,为不同的服务器群集配置其专用的证书

######配置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;
}

最后,配置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
}

完成以上配置后,重启Nginx,用不同浏览器客户端尝试访问您的站点,测试证书的部署策略是否生效。
如果再深入细致的对User Agent进行策略定制,将可以更细致的控制客户端的访问代理。
END

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章