Tag Archives

3 Articles

lua-resty-acme: ACMEv2客户端和Let’s Encrypt证书的自动化管理

0   10738 转为繁体

 

 

安装

使用opm:

opm中没有luaossl库,所以这种安装使用的是基于FFI的Openssl后端;需要OpenResty链接了大于等于1.1版本的OpenSSL。

也可以使用luarocks安装:

使用

以/etc/openresty目录为例,如果目录不存在,请自行修改。

生成一个账户密钥

生成一个默认证书

在Nginx配置的http 节插入以下内容

首次配置时,建议将init_by_lua_block中的staing = true取消注释,以防错误过多触发限流;测试通过后再加回注释使用生产API。

在需要使用证书的server节插入

CentOS/Fedora等系统的根证书在/etc/ssl/certs/ca-bundle.crt,请根据实际情况修改lua_ssl_trusted_certificate。

保存后,reload nginx。

在一般情况下,domain_whitelist必须配置,以防止恶意请求通过伪造SNI头进行拒绝服务攻击。

如果要匹配一系列域名,可以使用__index来实现。比如下面的例子仅匹配example.com的子域名:

RSA+ECC双证书

将init_by_lua_block中的domain_key_types = { 'rsa', 'ecc' }取消注释后,即可同时申请两套证书。

为了让申请到证书前的握手不出错断开,给Nginx配置默认的ECC证书

然后在server节中原有的ssl_certificate下增加两行

关于加密套件等的选择可借助搜索引擎。

TLS-ALPN-01

0.5.0开始支持tls-alpn-01,可以支持在只开放443端口的环境里完成验证。方法是通过蜜汁FFI偏移找到当前请求的SSL结构,然后设置了新的ALPN。需要多个stream server多次proxy,拓扑结构如下:

第一个stream server打开了443端口,根据请求的ALPN分发到不同的后段;如果是acme-tls则转发到我们的库,否则转发到正常的https。

示例配置见Github

Let’s Encrypt集中化管理

9   10921 转为繁体

Let’s Encrypt的证书签发原理实际上和传统的PKI一样,只不过自动化完成了生成CSR和私钥、提交CSR、取回证书的过程。

此外还要验证域名所属,这一部分和传统的签发机构是一样的,不过传统的签发机构还允许我们使用域名whois中填写的邮箱来验证,而Letsencrypt貌似只能通过http challenge的方式来验证。即和验证服务器约定一个uri和随机字符串,验证服务器请求这一uri,如果得到的内容和约定的随机字符串相同,则验证通过。如图所示:

letsencrypt_howitworks

官网上抄的)

这意味着我们得在每台部署https的前端的负载均衡服务器上都装一个letencrypt工具。有没有什么集中化管理的办法的呢?

实际上,由于challenge的uri的有规律,我们可以将前端服务器收到的这类请求代理到同一台专门用来签发、更新证书的服务器上。如图所示:

letsencrypt_howitworks_proxypass

  1. 当在服务器B上发起域名a.example.com新的签发请求后,Let’s Encrypt的签发服务器返回一个challange uri (8303)和response (ed98)。
  2. 服务器B使用webroot插件将这个uri和response写入本地磁盘上对应的文件。
  3. Let’s Encrypt的签发服务器为了验证example.com的所属,查询到example.com指向前端服务器A,于是发送一个HTTP请求/.well-known/acme-challenge/8303到服务器A
  4. 服务器A反代这一请求到服务器B
  5. B读取刚才第二步时写入到response,返回到A;A返回到Let’s Encrypt的签发服务器
  6. 验证成功,发证!

然后,我们只要从服务器A上取回存储在B上到证书就可以了。可以在B上做一个RESTful的api。注意要配置allow和deny。

A服务器(前端)的nginx配置如下:

B服务器的nginx配置如下:

然后在B上运行: