HTTPS环境使用第三方CDN的证书难题与最佳实践 | 高可用CDN架构详解

Posted 2021-04-30 高可用架构

上一篇《CDN对流媒体和应用分发的支持及优化》发出后得到了业界广泛的关注（点击文末“阅读原文”可进），文章介绍的CDN架构都是基于HTTP的，在目前互联网环境，基于安全的考虑，越来越多网站开始全面使用HTTPS，马涛专家在参考业界不同的方案后，在本文给出了详细的方案分析及建议。

问：在使用第三方CDN时，客户https证书是怎样管理的？

答：

目前的 HTTPS 和 CDN 其实并不完全兼容, 这主要是由于两者的工作模式互相透明, 反而引入了问题。

我们先简单解释一下 HTTPS 的工作方式, 再来介绍为什么 CDN 一般不好去支持 HTTPS。

HTTPS 是通过加密通过传送 HTTP 协议。 目前为止的加密通道主要是 TLS。 而经常提起的 SSL 因为其各个版本都存在缺陷, 其实已经不作为推荐使用了。 那么 HTTPS 是如何工作的呢?

这里最主要的一件事情就是服务器需要将其证书发送给客户端，客户端根据证书的信息，判断证书的合法性。这里的证书是 X.509 标准。证书可以认为是一种无法被伪造的身份证，关于其防止被伪造的方式这里就不再深入。这个证书中有一些至关重要的配置信息，可以使得客户端相信服务器是“真正的请求服务器”。一般情况下，证书中包含类似域名的信息，这样根据前面提到域名和证书中的域名，进行规则对比，即可判断连接服务器是否合法。

上面的验证域名过程，就是 HTTPS 中两个核心功能之一：验明身份。保证你的连接目标是合法的，且是你希望通信的目标。身份验证通过后，客户端和服务器端，还需要利用非对称密钥，传输此次会话的对称密钥。这样，客户端服务器之间就建立了一条安全，可信的通信方式。HTTP 协议就可以利用这个安全的信道，进行传输。

聪明的读者想必已经知道 CDN 为什么和 HTTPS 不完全兼容了吧？

因为几乎所有的 CDN 厂商都使用CNAME别名方式，在 DNS 解析过程中，将请求转到 CDN 服务器上，因此对于建立 HTTPS 的实体（例如：浏览器）来说，它认为它仍然在和原始网站通信，因此，如果 CDN 厂商的服务器不能返回“正确的”证书，那么 HTTPS 就能识别出该服务器是有问题的。

刚才我们说过，HTTPS 检测证书合法性的方法就是通过确认证书合法，且域名匹配来判断的。那么 CDN 厂商应该如何解决上面的问题呢？

目前有两种方案：

1.客户将自己的证书和非对称密钥 通通交给 CDN 厂商。（Custom Certificate）

2.客户将加速域名，授权给 CDN 厂商，CDN 直接用自己的证书（包含客户授权的域名）返回给客户端。（Shared Certificate）

这两个方案中方案1最大风险在于，其违背了证书和非对称密钥 设计思路。将私有信息完全暴露给第三方。

方案2的问题在于，目前大部分最新的浏览器，能够智能将证书的一些信息通过视觉化信息传递给用户。但是，如果使用了CDN厂商的证书，一般情况下，间接降低了安全提示信息（证书实际是分不同级别的，价格和存储的信息也不同，这里就不再做扩展了）。

大部分国外CDN都支持方案1，绝大部分支持方案2。

另外 HTTPS 使用时候，性能比较容易受到影响，也需要仔细调优。当然，HTTPS的安全，还需要专家来保驾护航。任何的漏洞，都会可能被不法之徒利用造成伤害。可用CDN架构详解

想进一步了解CDN的架构细节？或想同群专家进一步交流CDN经验及高可用架构，可回复arch申请进群。