阿里云 CDN HTTPS 最佳实践系列——动态证书（一）

背景

了解阿里云 CDN 架构的朋友应该知道，阿里云 CDN 7层的接入组件是 Tengine，我们知道 Tengine 原生是支持 SSL 的，只需要在配置文件中配置证书和私钥即可。在 CDN HTTPS 产品化以前，要开通 HTTPS 的域名需要把证书私钥给我们，我们在 Tengine 静态配置中配置，然后再同步到所有 CDN 边缘节点，显然这种方式在越来越多的域名开通 HTTPS 后，Tengine 静态配置文件会越来越大，难以管理，同时也会导致 Tengine reload 变得很慢，这样配置生效的时间就很糟糕，还有私钥安全等等一系列问题。所以 CDN HTTPS 产品化时就必须采用动态证书的方式，目前阿里云 CDN HTTPS 证书配置之后1分钟内生效，极大的提高了证书管理效率和用户体验。这两种方式的简单对比如下：

架构

动态配置的同步有两种方式：

1. 主动同步
       当用户在用户控制台上配置证书和私钥之后主动向下同步到 CDN 所有节点的 Tengine 中，这样当配置同步成功后用户域名的 https 访问就正常了，但是这种方式有很多缺点，因为 Tengine 机器有几千台，甚至上万台，把证书私钥同步到这么多机器用时较大，生效时间较慢，另外其他一些域名并不是访问到所有的 CDN 机器，如果把证书私钥同步到这台机器并没有什么用，白白浪费内存，以及影响证书的搜索性能。这种方式适合在少量机器群集中使用。
2. Lazy pull
       当 https 请求到达 Tengine 后，Tengine 再去拉取配置，这样就只拉取该机器有访问的域名配置，其他域名配置不需要拉取，解决了 Tengine 静态配置过多的问题，也避免了 Tengine reload，从而生效时间更快。

综合以上两种方式的优点，阿里云 CDN 在节点机房内部采用了 Lazy pull 方式拉取配置，在节点机房和中心机房之前采用主动同步的方式。以下是简化的 HTTPS 动态配置架构图。

实现

主动同步有很多种方式可以选择，比如 redis、zoomkeeper等等，这里只讲 Lazy pull 的实现，其关键技术是基于 Tengine 的指令 ssl_certificate_by_lua_file，这个指令是 lua-nginx 模块提供的，其用途就是在 openssl 中查找证书时的一个 lua 回调，然后在 lua 中动态设置证书和私钥。总之，如果 Tengine 的 server 块中配置了这个指令的话，当 openssl 在处理 SSL 握手消息 ClientHello 时会调用到这个指令配置的 lua 代码，在 lua 中我们可以做我们想做的事情，比如发 http 请求去远程拉取证书和私钥，做配置缓存，私钥加解密处理，动态设置证书和私钥等等一系列业务逻辑。

以下是 Tengine 的配置：

server {    listen  0.0.0.0:443 default_server ssl http2;    ssl_protocols                     TLSv1 TLSv1.1 TLSv1.2;    #ssl_ciphers                      [xx];    ssl_prefer_server_ciphers         on;    ssl_certificate                   default.crt;    ssl_certificate_key               default.key;    ssl_certificate_by_lua_file       dycert.lua;    include                           dyconf.cfg;}

如上配置，dycert.lua 是阿里云 CDN 实现的动态证书模块，在 SSL 完整握手时会调用到这个模块，在 Session 复用的握手情况下不会调用到这个模块，这是因为 Session 复用时不需要证书和私钥，这是 openssl 回调接口的官方实现，但是阿里云 CDN 的实现中，还有很多 HTTPS 的动态配置需要在 dycert 模块中来设置，所以我们修改了 openssl，让其在 Session 复用时也调用到 dycert 模块，这为我们实现很多 HTTPS 动态配置（比如： HTTP/2 开关，客户端认证，TLS record size 配置）提供了方便。

如下图所示，dycert 模块是所有 HTTP(S) 业务模块的第一个重要模块，当 https 请求到达 CDN Tengine 时，dycert 模块会去远程拉取 HTTPS 动态配置（证书、私钥、HTTP/2 开关、客户端证书、TLS record size 配置等等），然后解密私钥，将证书和私钥设置到 openssl 中，让其恢复 SSL 握手流程。握手成功后会将该请求交给 Tengine 的后续业务模块处理。

下面是 dycert 模块的实现原理图：

众所周知，Tengine 是多 worker 的，我们需要使用共享内存来缓存拉取到的动态配置，这样可以防止多个 worker 进程同时去远程拉取同一份配置，并且在 worker 进程内存中也同时做了缓存以提高效率。

当一个 https 请求调用到 Tengine dycert 模块时，先在本 worker 缓存中查询是否存在配置，如果没有就去共享内存中查询，如果还是没有就得去远程拉取了（远程拉取采用 http 的 resty api 方式），拉取到动态配置之后在本 worker 中缓存，同时也在共享内存中缓存，为了防止共享内存暴增，加了一个定时器来删除该域名的配置，下次从共享内存中查询不到配置再重新从远程拉取。

另外一个重点就是配置的更新后如何实时生效了：配置管理系统 agent 是可以实时发现域名的配置变化的，并且提供了配置变更注册机制，dycert 会定时的去注册 HTTPS 配置变更，并提供一个 purge resty api，当配置管理系统 agent 发现配置更新之后会回调到该接口，然后该接口会从共享内存中删除该域名的配置，下次该域名的 https 请求到达 dycert 模块后，发现共享内存中没有配置会再去配置管理系统 agent 中拉取，从而解决了配置更新后实时生效的问题。

以上为本文内容。目前，阿里云CDN HTTPS已经全面降价，后付费HTTPS 0.05元/万次请求。下一篇我们将介绍HTTPS最佳实践——HTTP/2，敬请期待。