0. 背景
無料のSSL証明書ということで話題のLet's Encryptですが、実際の利用のためには 90日ごと に証明書を更新しないといけないという制約から、なかなか本番利用するには腰が重くなってしまいます。
(もちろん本家では、全自動で更新することを推奨しています。)
ましてや、AWS ELBなどのロードバランサーを利用し、配下に複数のWebサーバがいると、ACMEプロトコルを通過させるだけで一苦労です。
そこで、nginxのリバースプロキシを使うことで、既存のアプリケーションに影響をあたえること無く、Let's Encryptの更新を済ませる方法を試しました。
1. 前提
今回は、以下の様な環境を想定します。
- 
www.example.comで受けるELBの配下に複数のWebサーバがある
- 
stg.example.comで受けるELBの配下にWebサーバがある
- 
www.example.comとstg.example.comに利用する証明書は1つにまとまっていて良い
2. letsencrypt実行サーバの用意
Amazon Linuxからのletsencryptの実行はまだ不安定で、本番利用のサーバに不要なライブラリをインストールしたくはないので、あたらしくletsencrypt実行専用のサーバを用意します。
今回は、CentOS7を利用しました。
サーバ起動後に必要な依存関係は git のみです。
その後、letsencryptをインストールします。
また、後述のリバースプロキシのために、firewalldを切っておきます。
(firewalldを閉じる前に、セキュリティグループが閉じていることを確認してください)
# yum install git
# systemctl stop firewalld.service
# cd /usr/local/src
# git clone https://github.com/letsencrypt/letsencrypt.git
# cd letsencrypt
これでサーバの準備は完了です。
Route 53から、letsencrypt.example.comというドメインがこのサーバを指すようにレコード指定しておきましょう。
このまま、以下のコマンドを実行するとLet's Ecnryptから証明書を取得しますが、指定したすべてのドメインへのリクエスト(ACMEプロトコル)が自分のサーバに届かないといけないので、失敗します。
3. リバースプロキシの設定
www.example.comとstg.example.comへのアクセスがletsencrypt実行サーバへ迂回するように、それぞれのサーバで動いているnginxのリバースプロキシ設定を行います。
Let's EncryptのACMEプロトコルは /.well-known/... へアクセスしてくるので、このディレクトリだけプロキシすれば十分です。
この設定のおかげで、本番環境への影響がなくなります。
server {
  listen 80;
  server_name www.example.com;
  ...
  # lets encrypt ACME proxy
  location /.well-known {
    proxy_pass http://letsencrypt.example.private;
  }
}
ここで、リバースプロキシ先のホストをletsencrypt.example.privateと置くことで、次回更新時に同じ作業をスキップすることができます。
その後は、Route 53でletsencrypt.example.privateのPrivate DNSを設定しましょう。
4. letsencryptの実行
letsencrypt実行サーバに戻ってletsencryptコマンドを実行しましょう。
# pwd 
/usr/local/src/letsencrypt
# ./letsencrypt-auto certonly --standalone -d www.example.com -d stg.example.com -d letsencrypt.example.com
上記を実行すると、以下のディレクトリに証明書が生成されます。
# cd /etc/letsencrypt/live/letsencrypt.example.com
# ls
cert.pem  chain.pem  fullchain.pem  privkey.pem
privkey.pemをプライベートキー、fullchain.pemをパブリックキー証明書 と読み替えて、ELBのSSL証明書を設定します。
以上で、ダウンタイムなしのELBの証明書更新が完了します。
今回は試していませんが、AWS CLIを利用することで、全自動にすることも可能です。
5. まとめ
無料で使えるSSL証明書とはいうものの、その設定にはまだ枯れていない部分があります。
TokyoリージョンでのAWS Certificate Managerが利用できるまではこの記事が役に立つのではないでしょうか?




