Tag Archives

3 Articles

lua-resty-acme: ACMEv2客戶端和Let’s Encrypt證書的自動化管理

0   13334 轉為簡體

 

 

安裝

使用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   11874 轉為簡體

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上運行: