Docker nginx＋CertbotでLet's Encrypt証明書を複数ドメイン1本に統合し、自動更新する方法
1：要約
Dockerでnginxを運用しているVPSで、Let's Encryptの証明書が複数作成され、 どの証明書をnginxが利用しているのか分かりにくくなっていました。 また、Certbotによる証明書更新も自動化されておらず、証明書の期限切れが発生していました。
そこで今回は、複数のドメイン・サブドメインを 1つのLet's Encrypt証明書に統合し、 Docker版Certbotとsystemd timerを使って自動更新する構成に整理します。
この記事では例として、以下の4ドメインを利用します。
example.com
www1.example.com
www2.example.com
www3.example.com最終的な構成は次のようになります。
Let's Encrypt
↑
│ HTTP-01認証
│
Docker nginx
│
├─ /.well-known/acme-challenge/
│
↓
/srv/web/certbot/www
Docker Certbot
│
├─ 証明書管理名：example.com
│
└─ 4ドメインを1証明書で管理
│
↓
/srv/web/certbot/conf
systemd timer
│
↓
docker run certbot renew
│
↓
更新成功時のみ nginx reloadポイントは、Ubuntu本体にCertbotを追加インストールせず、 公式のDocker版Certbotに統一することです。 Certbotを二重管理しないため、後から見ても構成が分かりやすくなります。
3：内容
3-1．今回の構成
nginxとCertbotはDockerで動かし、証明書データだけをVPS上の永続ディレクトリに保存します。
/srv/web/certbot/
├── conf/
│ ├── live/
│ ├── archive/
│ └── renewal/
│
└── www/
└── .well-known/
└── acme-challenge/役割は次の通りです。
/srv/web/certbot/conf：証明書、秘密鍵、Certbotの更新設定/srv/web/certbot/www：Let's EncryptのHTTP-01認証で使用
nginxコンテナとCertbotコンテナから同じディレクトリを見ることで、 nginxを停止せずに証明書を更新できます。
3-2．Let's Encrypt証明書を複数ドメインで1本にする
Let's Encryptでは、1枚の証明書に複数のDNS名を含めることができます。
今回は次の4ドメインを1枚にします。
example.com
www1.example.com
www2.example.com
www3.example.com
Certbot上の管理名も、分かりやすく
example.com に統一します。
最終的には次のようになります。
Certificate Name: example.com
Identifiers:
example.com
www1.example.com
www2.example.com
www3.example.comサブドメインごとに証明書を作る必要がなければ、 このようにまとめた方が管理対象を減らせます。
3-3．nginxとCertbotのディレクトリ共有
nginxには、例えば次のようにマウントします。
- /srv/web/certbot/conf:/etc/letsencrypt
- /srv/web/certbot/www:/var/www/certbot実際のマウント状態は次のコマンドで確認できます。
docker inspect nginx \
--format '{{range .Mounts}}{{println .Source " -> " .Destination}}{{end}}'例えば次のようになっていればOKです。
/srv/web/certbot/www -> /var/www/certbot
/srv/web/certbot/conf -> /etc/letsencrypt3-4．ACME challenge用のnginx設定
Let's EncryptのHTTP-01認証では、 HTTPの80番ポートから特定のURLへアクセスできる必要があります。
server {
listen 80;
listen [::]:80;
server_name
example.com
www1.example.com
www2.example.com
www3.example.com;
location ^~ /.well-known/acme-challenge/ {
root /var/www/certbot;
try_files $uri =404;
}
location / {
return 301 https://$host$request_uri;
}
}
通常のHTTPアクセスはHTTPSへリダイレクトしますが、
/.well-known/acme-challenge/ だけはCertbot用にHTTPでアクセス可能にします。
3-5．ACME challengeの疎通確認
証明書発行前に、テストファイルを作成します。
sudo mkdir -p /srv/web/certbot/www/.well-known/acme-challenge
echo 'certbot-test' | sudo tee \
/srv/web/certbot/www/.well-known/acme-challenge/test.txt各ドメインから確認します。
curl http://example.com/.well-known/acme-challenge/test.txt
curl http://www1.example.com/.well-known/acme-challenge/test.txt
curl http://www2.example.com/.well-known/acme-challenge/test.txt
curl http://www3.example.com/.well-known/acme-challenge/test.txtすべてで次の文字列が返れば正常です。
certbot-testこの確認を先に行っておくと、Certbot実行時の認証失敗をかなり減らせます。
3-6．4ドメイン入り証明書を発行する
公式Certbot Dockerイメージを使います。
docker run --rm \
-v /srv/web/certbot/conf:/etc/letsencrypt \
-v /srv/web/certbot/www:/var/www/certbot \
certbot/certbot certonly \
--webroot \
-w /var/www/certbot \
--cert-name example.com \
-d example.com \
-d www1.example.com \
-d www2.example.com \
-d www3.example.com成功すると、証明書は次の場所に作成されます。
/etc/letsencrypt/live/example.com/fullchain.pem
/etc/letsencrypt/live/example.com/privkey.pem
実ファイルはVPS側の
/srv/web/certbot/conf
に保存されているため、Certbotコンテナを削除しても証明書は残ります。
証明書一覧は次のコマンドで確認できます。
docker run --rm \
-v /srv/web/certbot/conf:/etc/letsencrypt \
certbot/certbot certificates3-7．nginxを新しい証明書へ切り替える
4つのHTTPS serverで同じ証明書を指定します。
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;nginx設定を確認します。
docker exec nginx nginx -t正常ならreloadします。
docker exec nginx nginx -s reload実際に読み込まれている証明書設定も確認できます。
docker exec nginx nginx -T 2>/dev/null \
| grep -E 'server_name|ssl_certificate'HTTPS通信も確認します。
curl -I https://example.com
curl -I https://www1.example.com
curl -I https://www2.example.com
curl -I https://www3.example.comHTTPステータスが200以外でも、アプリケーション側が400や302を返している場合があります。 重要なのはSSL証明書エラーが発生していないことです。
3-8．古い証明書を整理する
過去に複数の証明書を作っている場合、
live、
archive、
renewal
に古い設定が残っていることがあります。
まず一覧を確認します。
docker run --rm \
-v /srv/web/certbot/conf:/etc/letsencrypt \
certbot/certbot certificatesnginxが古い証明書を参照していないことを確認してから、 Certbot管理下の不要な証明書を削除します。
docker run --rm \
-v /srv/web/certbot/conf:/etc/letsencrypt \
certbot/certbot delete \
--cert-name 古い証明書名 \
--non-interactive/etc/letsencrypt/live配下を単純にrmするのは避けます。
Certbotは
live、
archive、
renewal
を連動して管理しているためです。
ただし、過去の作業で
live が消えているのに
archive と
renewal/*.conf
だけが残った壊れた設定では、手動整理が必要になる場合があります。
作業前にはバックアップを取っておくと安全です。
sudo tar -czf /root/letsencrypt-backup.tar.gz \
/srv/web/certbot/conf3-9．Certbotの自動更新テスト
自動化する前に、実際には証明書を更新しない
--dry-run を実行します。
docker run --rm \
-v /srv/web/certbot/conf:/etc/letsencrypt \
-v /srv/web/certbot/www:/var/www/certbot \
certbot/certbot renew \
--dry-run正常なら次のようなメッセージが表示されます。
Congratulations, all simulated renewals succeededここまで成功してから自動実行を設定するのが安全です。
3-10．systemd timerでCertbotを自動実行する
Docker版Certbotは、コンテナ自身がcronのように常駐して定期実行する構成ではありません。
そこでUbuntu側のsystemd timerを使って、 定期的にDocker版Certbotを起動します。
まずserviceを作ります。
sudo tee /etc/systemd/system/certbot-docker-renew.service > /dev/null <<'EOF'
[Unit]
Description=Renew Let's Encrypt certificates with Docker Certbot
Requires=docker.service
After=docker.service network-online.target
Wants=network-online.target
[Service]
Type=oneshot
RuntimeDirectory=certbot-renew
ExecStartPre=/usr/bin/rm -f /run/certbot-renew/renewed
ExecStart=/usr/bin/docker run --rm \
-v /srv/web/certbot/conf:/etc/letsencrypt \
-v /srv/web/certbot/www:/var/www/certbot \
-v /run/certbot-renew:/run/certbot-renew \
certbot/certbot renew \
--deploy-hook "touch /run/certbot-renew/renewed"
ExecStartPost=/bin/sh -c 'if [ -f /run/certbot-renew/renewed ]; then echo "Certificate renewed - reloading nginx"; /usr/bin/docker exec nginx nginx -s reload; else echo "No certificate renewal - nginx reload not required"; fi'
EOF
このserviceでは、証明書が実際に更新された場合だけ
nginx -s reload
を実行します。
次にtimerを作ります。
sudo tee /etc/systemd/system/certbot-docker-renew.timer > /dev/null <<'EOF'
[Unit]
Description=Run Docker Certbot renewal twice daily
[Timer]
OnCalendar=*-*-* 03,15:00:00
RandomizedDelaySec=30m
Persistent=true
Unit=certbot-docker-renew.service
[Install]
WantedBy=timers.target
EOFsystemdへ設定を読み込ませます。
sudo systemctl daemon-reloadtimerを有効化して、その場で開始します。
sudo systemctl enable --now certbot-docker-renew.timerこの例では1日2回、3時台と15時台にCertbotが更新チェックを行います。
毎回証明書を発行するわけではありません。
certbot renew
が更新期限を判断し、更新が必要な場合だけ証明書を更新します。
3-11．自動更新の状態を確認する
timerの状態を確認します。
systemctl status certbot-docker-renew.timer --no-pager次回実行時刻はこちらです。
systemctl list-timers --all | grep certbot有効化状態も確認できます。
systemctl is-enabled certbot-docker-renew.timer
systemctl is-active certbot-docker-renew.timer正常なら次のようになります。
enabled
activetimerを待たずにserviceだけ手動実行することもできます。
sudo systemctl start certbot-docker-renew.service実行ログを確認します。
sudo journalctl \
-u certbot-docker-renew.service \
-n 100 \
--no-pager証明書を取得したばかりの場合は更新されないため、 次のような内容になるのが正常です。
Certificate not yet due for renewal
No certificate renewal - nginx reload not required3-12．省保守化のポイント
今回の構成で重要なのは、Certbotや証明書の管理方法をできるだけ増やさないことです。
最終的には次の状態を目指します。
証明書
└─ example.com
├─ example.com
├─ www1.example.com
├─ www2.example.com
└─ www3.example.com
Certbot
└─ Docker版のみ
認証方式
└─ webroot
定期実行
└─ systemd timer
Webサーバー
└─ Docker nginxUbuntuへ別のCertbotをインストールすると、 「OS版Certbot」と「Docker版Certbot」の2系統が存在することになります。
特別な理由がなければ、今回のようにDocker版Certbotだけに統一した方が、 数か月後に設定を見直したときにも理解しやすくなります。
また、証明書をサブドメインごとに分割すると、 renewal設定、証明書ファイル、期限確認対象も増えます。
同じサーバーで利用していて、同じタイミングで更新して問題ないドメインなら、 1枚の証明書へまとめることで保守対象を減らせます。
最終チェック用コマンド
# 証明書一覧
docker run --rm \
-v /srv/web/certbot/conf:/etc/letsencrypt \
certbot/certbot certificates
# 更新シミュレーション
docker run --rm \
-v /srv/web/certbot/conf:/etc/letsencrypt \
-v /srv/web/certbot/www:/var/www/certbot \
certbot/certbot renew --dry-run
# nginxが使用している証明書
docker exec nginx nginx -T 2>/dev/null \
| grep -E 'server_name|ssl_certificate'
# timer確認
systemctl list-timers --all | grep certbot
# 更新ログ
sudo journalctl \
-u certbot-docker-renew.service \
-n 100 \
--no-pagerこの構成にしておけば、通常の運用ではCertbotを手動で操作する必要はほとんどなく、 systemd timerが定期チェックし、必要なタイミングで証明書を更新できます。
