SSL/TLS証明書の更新を止めない：自動化と期限監視の設計

この記事の結論

証明書は最初に発行できれば完了ではありません。更新に必要な通信やDNS権限が失われたり、更新済みの証明書が配信先へ反映されなかったりすると停止につながります。発行・配布・実際の配信を分けて確認します。

利用者が接続するCDNやロードバランサーと、その裏にあるWebサーバーが、それぞれ証明書を持つ構成があります。ドメイン名、有効期限、管理サービス、更新担当、配信先を台帳にします。管理画面に表示された証明書だけでなく、利用者が実際に接続する終端を監視対象にします。

ACMEによる認証では、HTTPで所定の応答を返す方式や、DNSに指定情報を設定する方式などがあります。Let's EncryptのHTTP-01ではポート80を利用し、DNS-01では所定のTXTを使います。WAF・転送設定・DNS管理先を変えるときは、既存の更新経路を壊さないか確認します。

DNS認証にAPIを使う場合、サイトが侵害されたときにドメイン全体まで操作されないよう、可能な範囲で権限を限定します。秘密情報は公開リポジトリに置かず、保管先と更新担当を決めます。マネージドサービスの場合も、誰が証明書を更新し、失敗を誰に通知するのかを確認します。

更新処理が成功しても、配信機器への反映や再読み込みが失敗している可能性があります。外部からの接続で、対象名・期限・証明書チェーンを確認します。期限通知は作業に必要な余裕を確保できる段階に設定し、最初の通知を見落とした場合の連絡先も用意します。

Let's Encrypt：Challenge Types — HTTP-01・DNS-01の条件とDNS API権限への注意。期限監視と台帳は編集部の運用提案です。

参照確認：2026年9月21日。参照範囲は各資料の説明に記載しています。手順・比較軸・設計例は編集上の提案です。価格や個別契約条件を保証せず、実環境での動作・性能は未検証です。製品選定・設定変更の前に、契約先の最新条件を確認してください。

制作にはAIによる原稿作成の補助を使用しています。公式資料の説明と編集上の提案を区別し、具体例は設計上の仮定として掲載しています。