このページのCertbotコマンドと設定はNginx用です。Apache・Caddyの設定へそのまま適用しません。特にCaddyの自動HTTPSはCaddyのページで前提を確認します。
01 / ドメインとDNSを用意する
NginxとPHP-FPMの手順を終え、サーバーの管理接続とバックアップを確保します。本番公開では、所有・管理できるドメインと外部から到達できるサーバーが必要です。このページの example.com は説明用で、必ず自分のドメインへ置き換えます。
- ドメインを取得するか、管理者からDNS変更権限を用意してもらいます。
- 利用する名前のAレコードをサーバーの公開IPv4へ設定します。AAAAはサーバーまでIPv6で到達することを確認できる場合だけ設定します。
- 既存のWebサイト・メール・ほかのDNSレコードへの影響を確認します。DNSはこの構築対象のサーバーへ向けます。本手順書を公開しているCloudflare Pagesへ向ける操作ではありません。
自宅回線のNATではルーター側の転送設定等も必要です。CGNATや回線の制限で外から到達できない場合、このHTTP-01方式をそのまま使うことはできません。VPS等の公開経路を用意するか、公式のチャレンジ方式を確認してください。
完了条件は、自分が設定した名前が予定する公開IPへ解決されることです。ドメイン未取得の段階では、次の証明書取得を実行せず、前のページまでのローカル動作確認にとどめます。
02 / ドメインでHTTPに到達することを確認する
サーバーで sudoedit /etc/nginx/sites-available/server-guide を開き、前の手順の server_name _; を server_name example.com; に変更します。www等の別名を使う場合は、その名前のDNSと証明書も別途必要です。既存の設定をバックアップし、PHPの設定を残します。
sudo nginx -t && sudo systemctl reload nginx構文検査に失敗した場合は再読み込みせず修正します。UFWを使っている場合は、管理用SSHの許可を維持したままHTTP/HTTPSを許可します。クラウド側のFWやルーターも確認してください。
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status verbose別ネットワークの端末から次を実行します。80番が外から通り、構築したページが返ることを確認してください。サーバー自身のlocalhostだけの成功では代用できません。
curl -I http://example.com/到達しなければDNS、A/AAAA、NAT、クラウドFW、UFW、Nginxの順に確認します。認証情報やWordPress管理画面は、HTTPSを確認するまで外部へ公開しません。
03 / Let's Encryptの証明書を取得する
ここからはドメインと80番への外部到達確認を終えた場合の、Certbot公式資料に基づく手順です。実ドメインを使った発行は本サイトでは未検証です。Ubuntuの公式リポジトリから導入します。
sudo apt-get update && sudo apt-get install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com --redirect所有する実ドメインへ置き換えて実行し、メールアドレス・利用規約等の対話に応答します。CertbotはNginx設定を書き換えるため、変更前の設定を保管してください。成功した場合だけ、表示された証明書名・期限と設定の変更箇所を確認します。
認証失敗は、証明書発行の成功ではありません。エラーと /var/log/letsencrypt/letsencrypt.log を読み、DNSや到達経路を直してから再試行します。失敗のまま繰り返して発行制限に達しないよう、Certbot公式資料を参照します。
04 / HTTPSと更新を確認する
サーバーの設定検査と、別端末からの通信を確認します。TLSエラーを -k で無視せず、ドメイン名・有効期限・証明書チェーンを調べます。
sudo nginx -t
sudo certbot certificates
curl -I http://example.com/
curl -I https://example.com/完了条件は、HTTPがHTTPSへ転送され、HTTPSで意図したページが返り、ブラウザーが証明書エラーを表示しないことです。HTTPからHTTPSへの転送にループがないことも確認します。
systemctl list-timers --all | grep certbot
sudo certbot renew --dry-runタイマーが予定され、更新の試行が成功することを確認します。--dry-run は更新経路のテストで、本番証明書の実更新ではありません。日々の監視で期限と更新ログも確認します。更新が失敗したら、外部到達性と設定を修正し、期限切れ前に対処してください。
設定変更を戻す場合は、先に必要な外部公開を止めます。HTTPだけの設定へ戻したままWordPress等へログインせず、HTTPS復旧を確認するまで認証情報を送らないでください。バックアップしたサイト設定を復元し、sudo nginx -t && sudo systemctl reload nginx を実行します。証明書・鍵はWeb公開領域へ置かず、不要な鍵を記事やGitへ載せません。
05 / 検証範囲
ドメインは未定です。DNS変更、Let's Encryptの実証明書発行、インターネットからのHTTP-01認証、自動更新の実行は未検証です。上記は公式資料に基づく運用手順で、取得済みと示す証明書画像は掲載しません。
検証VMでは専用のローカルCAとserver-guide.test用証明書を作り、CAとホスト名を検証したHTTPS応答を確認しました。信頼していないCAと異なるホスト名は、それぞれcurl終了コード60で拒否され、HTTPからHTTPSへの301転送も確認しています。証明書検証を無効にした確認ではありません。このローカル試験は公開ドメインやLet's Encryptの証明書発行の代わりにはなりません。
