Let's Encrypt集中化管理 ; 論野生技術&二次元

Let’s Encrypt的證書籤發原理實際上和傳統的PKI一樣，只不過自動化完成了生成CSR和私鑰、提交CSR、取回證書的過程。

此外還要驗證域名所屬，這一部分和傳統的簽發機構是一樣的，不過傳統的簽發機構還允許我們使用域名whois中填寫的郵箱來驗證，而Letsencrypt貌似只能通過http challenge的方式來驗證。即和驗證伺服器約定一個uri和隨機字元串，驗證伺服器請求這一uri，如果得到的內容和約定的隨機字元串相同，則驗證通過。如圖所示：

letsencrypt_howitworks

（官網上抄的）

這意味著我們得在每台部署https的前端的負載均衡伺服器上都裝一個letencrypt工具。有沒有什麼集中化管理的辦法的呢？

實際上，由於challenge的uri的有規律，我們可以將前端伺服器收到的這類請求代理到同一台專門用來簽發、更新證書的伺服器上。如圖所示：

letsencrypt_howitworks_proxypass

當在伺服器B上發起域名a.example.com新的簽發請求後，Let’s Encrypt的簽發伺服器返回一個challange uri (8303)和response (ed98)。
伺服器B使用webroot插件將這個uri和response寫入本地磁碟上對應的文件。
Let’s Encrypt的簽發伺服器為了驗證example.com的所屬，查詢到example.com指向前端伺服器A，於是發送一個HTTP請求/.well-known/acme-challenge/8303到伺服器A
伺服器A反代這一請求到伺服器B
B讀取剛才第二步時寫入到response，返回到A；A返回到Let’s Encrypt的簽發伺服器
驗證成功，發證！

然後，我們只要從伺服器A上取回存儲在B上到證書就可以了。可以在B上做一個RESTful的api。注意要配置allow和deny。

A伺服器（前端）的nginx配置如下：

server {
    # 其他的location
    # location { ..... }

    location ~ /.well-known {
        proxy_pass http://B.example.com:23333;
    }
}

server {

# 其他的location

# location { ..... }

location ~ /.well-known {

proxy_pass http://B.example.com:23333;

}

B伺服器的nginx配置如下：

server {
    listen 23333;
    server_name B.example.com;
    location ~ /.well-known {
        root /tmp/letsencrypt;
        allow IP-OF-A;
        deny all;
    }
}

server {

listen 23333;

server_name B.example.com;

location ~ /.well-known {

root /tmp/letsencrypt;

allow IP-OF-A;

deny all;

}

然後在B上運行：

./letsencrypt-auto --webroot -w /tmp/letsencrypt -d exmaple.com;

1	./letsencrypt-auto --webroot -w /tmp/letsencrypt -d exmaple.com;

Let’s Encrypt集中化管理