Certbotで更新したのにHTTPSの証明書が古い：保存・配備・外部応答を分ける
Certbotの終了コード0だけでは、新しい証明書をHTTPSで配信できたとは判断できません。保存済み証明書、TLSを終端する場所、実際の接続先が返す証明書を照合してから、必要な配備操作を決めます。
公式資料確認日：。
最初に、どこがHTTPSを終端しているか決める
対象は自己管理のCertbotとNGINXです。CDNやロードバランサーが手前でTLSを終端する場合、ブラウザが見るのはその終端の証明書です。手元のNGINXのファイルを更新しても、別の終端まで同時に更新されたとは受け入れません。
対象ホスト名、接続ポート、終端の担当、証明書の有効期限を一行へ書きます。コンテナの場合は、Certbotの保存先とNGINXから見えるパスが同じ証明書へ届くことも照合します。秘密鍵の内容はこの記録へコピーしません。
更新処理の成功と、公開側の成功を三段階で記録する
certbot certificatesで保存済み証明書の名前・期限・パスを参照し、NGINXのssl_certificateの指定先と対応させます。その後、対象名への新しいTLS接続で返る証明書の名前と期限を比べます。CDNを経由する接続と、許可されたoriginへの確認は別の行にします。
| 観測 | 判定できる範囲 | 次の行動 |
|---|---|---|
| renewの終了コード0 | 更新成功、または更新が不要 | 更新対象と実際の期限を読む |
| 保存済みは新しいが接続先は古い | 配備先・再読込み・別終端が候補 | 終端と設定パス、配備ログを照合 |
| reload後も期限が変わらない | 適用失敗や別経路を除外できない | NGINXのエラーログと接続先を調べる |
| 対象名への新接続で期待した期限 | その接続経路での反映 | ほかの必要ホスト・終端を別途受け入れる |
reloadとdeploy-hookは、担当と戻し方が決まってから
NGINXはreloadで新設定を評価します。適用できなければ旧設定で継続するため、reloadの命令を送ったことだけで反映を合格にしません。既存設定を保全し、対象のプロセス・権限・設定が分かった担当者が配備を行い、ログと新しい接続で結果を受け入れます。
Certbotのdeploy-hookは更新成功後に配備処理を行う仕組みです。ただしhookの失敗が直接Certbotの終了非0になるとは限りません。更新の記録と配備の記録を分け、期限内に公開応答が変わらなければ担当へ通知する条件を残します。
dry-runは公開HTTPSの配備試験とは別
現行Certbot 5.8の公式説明では、dry-runは通常deploy-hookを実行しません。pre/post hookや一時的な設定変更・reloadは起こり得るので、無変更の読取り検査として本番へ実行しません。試験する場合は既存hookの副作用と実行する版の仕様を先に照合します。
想定例として、保存先の期限が12月、公開接続の期限が10月なら、先に配備と経路を調べます。ここでの月は記入例であり実測ではありません。期限までの余裕と復旧に必要な時間から通知時点を決めます。
更新を繰り返す前に止める条件
終端や秘密鍵の所在が不明なら、再発行・再起動・検証無効化へ進まず担当を確定します。証明書を何度も強制更新することを、配備不明の解決にはしません。管理サービス側の終端なら、そのサービスの公式更新手順へ切り替えます。
公式資料と、判断例の境界
仕様の根拠は以下の公式資料です。本文の記入例は実測値ではありません。購入・設定変更時は、対象の型番・版・契約条件を照合します。
- Certbot：更新、配備hook、dry-runの範囲
renewの終了0は更新不要でも返ります。deploy-hookは更新成功後の操作。hook失敗が直接Certbotの終了非0になるとは限りません。dry-runは通常deploy-hookを実行せず、無変更の検査でもありません。
- NGINX：設定再読込みの動作
reloadで新設定を評価し、有効なら新workerへ移行、適用できなければ旧設定で継続します。
- NGINX：HTTPS証明書の指定
ssl_certificateはサーバーが使う証明書ファイルを指定します。接続名とTLS終端・設定先を一致させます。