SSL証明書の更新は、管理画面の期限を延ばすだけの処理ではありません。認証局によるドメインの管理確認と証明書の発行が必要です。その証明書をすべての入口へ配備し、外部から正しいものが返ることを確かめるまでが一連の更新です。

自動更新の失敗を「期限切れ」の一言で扱うと、原因とは違う操作を繰り返してしまいます。検証・発行・配備・公開確認のどこで止まったかを分けると、警告表示になる前に直せる範囲が見えてきます。

警告は期限切れ以外でも表示される

証明書には利用できる期間があり、接続時には現在時刻がその範囲内か確認されます。RFC 5280では、有効期間に加えて、信頼できる認証局までの経路を検証する仕組みが定められています。そのため、期限内の証明書でも中間証明書の配備が欠けていれば、利用環境によって警告になることがあります。

もう一つの確認がホスト名です。RFC 6125に沿った検証では、利用者が開いたホスト名と証明書に含まれる名前を照合します。example.jpの証明書が正常でも、www.example.jpやキャンペーン用サブドメインが対象に入っていなければ、そのURLでは名前の不一致になります。

更新トラブルを調べるときは、有効期限だけを見て終わらせません。警告が出た正確なURLと証明書に含まれる名前を照合します。認証経路に加え、接続先が返している証明書も確認します。管理画面に保存された証明書と、利用者が受け取る証明書が同じとは限らないためです。

最初にドメイン確認の失敗を切り分ける

自動発行で使われるACMEでは、認証局が対象ドメインを管理していることを確認します。Let's Encryptのチャレンジ解説によると、HTTP-01は対象ドメインの決められたパスをポート80で確認し、DNS-01は_acme-challengeのTXTレコードを確認します。どちらを利用しているかで、調べる場所が変わります。

HTTP-01では、DNSが更新対象のサーバーを向いているか確認します。次に外部からポート80へ接続できるか、WAFや転送設定が確認用パスを妨げていないかを見ます。CDNやロードバランサーの背後に複数のWebサーバーがある場合は、どのサーバーへ到達しても確認用の応答を返せる必要があります。Let's Encryptの導入資料も、各フロントエンドから同じ検証応答を提供するよう案内しています。

DNS-01では、更新ツールが現在のDNS事業者へ書き込めるか、APIの認証情報と権限が有効かを確認します。ネームサーバーを移したのに古い事業者のAPI設定が残っていると、管理画面ではTXTを追加したつもりでも公開DNSには現れません。複数のDNSサーバーが異なる値を返していないか、古い確認用レコードが残っていないかも外部から確かめます。

発行成功とサイトへの反映は別の工程になる

ドメイン確認が通り、証明書ファイルが作成されても、サイトが新しい証明書を返すとは限りません。Webサーバーの再読み込みに失敗する、証明書と秘密鍵の組み合わせが違う、設定が別のファイルを参照しているといった配備上の問題が残るためです。更新ログでは、発行完了と配備完了を別の結果として読みます。

CDN・ロードバランサー・リバースプロキシを使うサイトでは、HTTPSを終端する場所が複数あります。利用者にはCDNの証明書が見え、CDNから配信元サーバーへの接続には別の証明書が使われる構成もあります。一か所だけ更新すると、接続経路やアクセス先によって新旧の証明書が混在します。

対象名の変更も配備時に起こりやすい問題です。URL統一やサイト追加でwww・管理画面用サブドメイン・外部公開APIが増えたら、自動更新の対象名も見直します。ワイルドカード証明書があっても、親ドメインやより深い階層を無条件に覆うわけではないため、実際に使うホスト名を列挙して確認する方が確実です。

再試行より先に更新ログと公開状態を見る

更新ボタンを何度も押しても、DNSや検証経路の原因は変わりません。証明書発行にはレート制限もあるため、Let's Encryptのレート制限資料が示すとおり、エラーを解消せず発行を繰り返す運用は避けます。最初の失敗時刻と対象名を残します。利用した検証方式と認証局から返ったエラーも必要です。

ログのエラーがHTTP確認なら、対象URLを外部回線から開いて応答を追います。DNS確認なら、公開されているTXTを複数のDNS応答で確かめます。発行済みなら、各TLS終端が参照するファイルとサービスの再読み込み結果を確認します。この順番なら、関係のないDNS変更と証明書再発行を同時に行わずに済みます。

修正後は、サーバー内のファイルではなく公開URLへ外部から接続します。非www・www・利用中のサブドメインを個別に開きます。返された証明書は有効期間・名前・認証経路を確認します。複数の接続先があるサイトでは時間や回線を変えて試し、一台だけ古い状態が残っていないかも見ます。

次回更新を公開側から監視する

証明書の期限通知だけでは、更新後の配備失敗を発見できません。監視対象は管理画面の期限ではなく、利用者が接続する公開URLから返る証明書にします。期限までの残り時間に余裕を持った通知と、名前不一致や認証経路の異常を検知できる確認を組み合わせます。

運用記録には更新方式・対象ホスト名・検証経路を残します。証明書の配備先に加え、通知先と最終確認日も必要です。DNS・CDN・サーバーの契約先が違う場合は、各社が担う工程を明記します。担当者が変わるとAPI認証や通知メールだけ古いまま残りやすいため、異動や契約変更の時点で更新経路も見直します。

自動更新を信頼できる状態とは、操作が自動化されていることではありません。失敗を期限前に検知でき、どの工程で止まったかを追え、公開中の証明書まで確認できることです。そこまでを定期運用へ含めると、警告が出てから慌てて再発行する対応から離れられます。