証明書ファイルを置き換えただけでは、利用者が接続する全TLS終端へ反映されたとは限りません。新旧のシリアル番号と接続先を対応づけます。
新旧証明書を「どこが返したか」で分ける
- 利用者が見たホスト名、時刻、証明書のシリアル番号・有効期間・発行者を保存する。
- DNSのA/AAAA/CNAMEを確認し、CDN/LB/オリジンのTLS終端一覧を作る。
- SNIを含めて外部から接続し、接続先IPごとに提示証明書を比較する。
- CDN/LBの証明書ステータスと、対象リスナー・ターゲットプロキシへの関連付けを確認する。
- 新証明書が全終端で出るまで、旧証明書を消す操作やDNSの一斉変更をしない。
症状から残っている終端を探す
| 症状 | 主な候補 | 確認 |
|---|---|---|
| IPv6利用者だけ旧証明書 | AAAA先・IPv6 LB | A/AAAA双方の接続先と証明書 |
| 地域により違う | CDNエッジ・複数リージョン | 地域別外部監視とエッジ状態 |
| wwwだけ、またはapexだけ古い | 別リスナー・別証明書 | SANとホスト別TLS終端 |
| 数回に一度だけ古い | LB配下の一部ノード | 接続先IP、セッション再利用を変えて比較 |
| オリジンは新、公開URLは旧 | CDN/LB | エッジ証明書と関連付け |
| 公開URLは新、監視だけ旧 | 監視先・SNI・DNSキャッシュ | 監視設定とリゾルバ結果 |
期限切れ、ホスト名不一致、チェーン欠落も同時に出る場合はSSL証明書エラー全体の手順へ戻ります。
CDN・ロードバランサーで見る箇所
Cloudflare
エッジ証明書の状態がActiveか、対象ホスト名を含むか、カスタム証明書の新旧が重複していないかを確認します。Cloudflareは置換証明書がActiveになるまで旧証明書を保持する設計を案内しています。
Google Cloud Load Balancing
Google管理証明書がACTIVEで、正しいターゲットプロキシに関連付けられているか、DNS A/AAAAがLBのIPを指すかを確認します。公式文書では管理証明書は90日で、自動更新は期限のおよそ1か月前から始まります。
複数オリジン・自前プロキシ
各ノードの証明書ファイルだけでなく、実際のプロセスが再読み込み済みか、正しいリスナーへ割り当てられたかを確認します。秘密鍵の一致を検証し、内容を外部へ貼り付けません。
してはいけないこと
- 原因確認のために秘密鍵をWeb診断サービスへアップロードする。
- 旧証明書を先に削除し、更新中の終端を停止させる。
- TLS検証を無効化、またはHTTPへ恒久的に戻す。
- DNS、CDN、LB、証明書を同時に変更して比較不能にする。
再発防止は「期限」ではなく「実提示」を監視する
保管庫の期限だけでなく、公開ホストへ外部接続して提示された証明書の期限・ホスト名・チェーンを監視します。www/apex、IPv4/IPv6、重要地域を分け、更新失敗と期限前通知の両方を設定します。
公開URLのSSLを外部監視する
UptimeRobotはSSL期限とエラーの監視を案内しています。既存監視との重複、確認間隔、通知先を比較し、必要な場合だけ導入します。
UptimeRobot公式のSSL監視を見る公式情報
よくある質問
ブラウザキャッシュを消せば直りますか？
一端末だけなら候補ですが、まず外部から接続先ごとの証明書シリアル・有効期間を比較します。複数利用者で旧証明書が返る場合は配布先やTLS終端の不一致を疑います。
新旧証明書が交互に出るのはなぜですか？
複数のCDNエッジ、LBリスナー、オリジン、IPv4/IPv6、リージョンの一部だけが更新されていない可能性があります。接続先IPとSNIを固定して各終端を比較します。
Google管理証明書がACTIVEなら完了ですか？
ACTIVEに加え、対象のターゲットプロキシへ関連付けられ、DNSのA/AAAAが対象LBを指していることを確認します。別のTLS終端が前段にある場合は、利用者が実際に受ける証明書も確認します。