SSL証明書期限切れの確認方法と復旧手順

SSL証明書が期限切れになったら最初に何をするか

証明書の警告でHTTPSに接続できなくなったら、利用者はログインや入力を止め、ホスト名・発生時刻・エラー表示を運用窓口へ伝えます。
管理者は端末時刻のずれと、サーバーが提示した証明書の有効期間を照合します。CDNがTLSを終端している場合は、端末からCDN、CDNからオリジンのどちらで失敗したかを確認します。
復旧の判断には、更新の成功通知に加えて、対象の経路が新規接続で有効な証明書を提示し、必要な業務操作が通ることを使います。

WebサイトやAPIのサーバー証明書を対象に、情報システム担当者、Web運用・開発担当者、SaaS管理者が確認を引き継げるようにまとめました。基準日の2026年5月18日までの公開仕様とベンダー資料を土台とし、2026年11月10日に公式情報を再確認しました。

• 記録する

  対象ホスト、警告、時刻、影響の範囲を集める。

• 区間を特定する

  端末、公開側のTLS終端、オリジンを分ける。

• 更新して確かめる

  新規TLS接続で提示内容を見て、業務の再開を判断する。

読者別に最初の確認を分担する

• サイトやSaaSの利用者は、普段使う正規のURLかを確認し、端末の自動時刻設定と警告の表示を運用窓口に伝えます。認証や決済は正常な接続が戻るまで止め、急ぎの業務は組織が指定した代替経路を使います。
• 情シス・SaaS管理者は、標準のサービスURLとカスタムドメインを分け、影響する利用者、委託先窓口、証明書とDNSの管理者を特定します。自組織の管理範囲に応じて、提供元へエラーと観測時刻を伝えます。
• Web運用・開発担当者は、公開側とオリジンのTLS終端、ロードバランサー（LB）やIngressのリスナーを台帳と構成図で確認します。Web表示に加えて、API・ログイン・決済など影響した業務も復旧確認に含めます。

証明書の期限切れと表示エラーの違い

SSL証明書と呼ばれることが多いサーバー証明書は、HTTPSで相手の名前と公開鍵の結び付きを確認するために使われます。有効期間は利用開始の notBefore から終了の notAfter までです。画面やログの時刻をJSTまたはUTCにそろえ、日付に加えて時分も比較します。詳細は記事末尾のRFC 5280を参照してください。

一台でだけ複数サイトの警告が出る場合は、時刻同期や管理プロキシの状態を優先して確認します。同じホストが複数の承認済み端末で失敗する場合は、サービス側の影響を疑って運用担当へ連絡します。結果が異なるときは、端末・ネットワーク・接続先の違いを残してください。

最初に確認するチェックリスト

1. 発生時刻と接続先。タイムゾーン付きの時刻、ホスト名、エラー表示、影響した画面や業務を記録します。URLのクエリに認証情報がある場合は伏せます。
2. 再現範囲。承認済み端末で同じホストを確認し、特定端末・社内経路だけか、外部利用者や監視にも及ぶかを分けます。業務停止時は再現確認と担当者への連絡を並行します。
3. 証明書が提示される場所。利用端末が見る公開側と、CDNが接続するオリジンを分け、ロードバランサーやIngressでTLSを終端していればその設定も確認します。
4. 提示された証明書。発行元、シリアル番号または指紋、SAN、有効期間、中間証明書を確認します。ホスト名を指定して接続し、端末・経路ごとの観測値を記録します。
5. 更新と配置の履歴。発行管理画面、更新ジョブ、DNS変更、配置・再読み込みのログを照合します。マネージド証明書では提供元の更新条件と、更新された証明書が使われるリスナーを確認します。

初動対応と復旧の判断基準

やること

公開ホストの証明書が期限切れなら、公開側のTLS終端を担当するチームへ連絡します。CDNで管理する証明書、LBに割り当てた証明書、自前で配置する証明書では、更新する場所が異なります。正規の発行・配置手順を使い、対象名、発行元、利用開始時刻、中間証明書を確認してから反映します。

Cloudflareの526がFull (strict)のWebサイトで出るときは、オリジンに到達する設定とそこで提示される証明書を確認します。公開側の証明書が有効でも、この区間で検証に失敗すると、利用者にはエラーが返ります。Cloudflare Origin CAを使う構成では、オリジンの証明書を実際に検証する側の信頼条件で確認します。

発行済みなのに旧証明書が提示される場合は、リスナーへの割り当て、設定が参照する証明書、再読み込みや配布の成否を調べます。複数ノード、IPv4とIPv6、別のホスト名など、経路が分かれる構成では、影響した経路ごとに確認します。Certbotの更新処理は、更新対象がない場合にも正常終了するため、発行の結果と配置後の観測を別々に監視します。

避ける操作

• 証明書警告を無視してログインや決済を続ける操作、TLS検証を無効にする恒久対応、HTTPへの切り替えは避けます。
• 原因の区間を確認する前に、CDN・DNS・LBの設定をまとめて変更したり、証明書の再発行を繰り返したりしないでください。
• 秘密鍵、認証トークン、内部設定の全文は報告票や外部検査サービスへ貼り付けません。

緊急度を上げる条件

• 至急。本番のログイン・決済・APIが停止した、複数端末で再現した、または外部監視で異常が出た場合は、障害窓口と証明書の管理者へ同時に連絡します。
• 調査を並行。想定外の発行元、DNS変更、秘密鍵の露出などが見つかった場合は、期限更新に加えてセキュリティ窓口へ報告します。露出の可能性があれば、鍵交換と失効の手順へ進みます。
• 予防対応。期限が近づいても接続が正常なら、残り時間を発行・審査・配置・確認に必要な時間と比べます。期限までに作業を終えられない見込みなら、担当者と委託先へ早めに引き継ぎます。

記録と復旧完了の確認

以下を社内の障害記録へ転記します。未確認の経路は担当者と再確認時刻を残してください。

• 初報。発見時刻、対象ホスト、エラー、影響した業務、利用端末・経路。
• 変更。失敗した接続区間、変更担当、旧・新の証明書識別子と期限、配置・反映時刻。
• 完了確認。新規接続で期待した証明書とチェーンが提示され、警告が消えたこと。影響した画面、APIや認証が通り、監視が回復したこと。
• 残件。確認できなかった接続経路、担当者、期限監視と再試験の予定。

よくある誤解と再発防止

「ブラウザで期限が新しくなったので、すべて復旧した」。ブラウザが確認できるのは、その接続で提示された証明書です。CDNとオリジンが別のTLS区間を持つ構成では、両区間と影響した業務を確認します。

「有効期間が200日なら200日おきに更新すればよい」。CA/Browser Forumの規程では、2026年3月15日以降、2027年3月15日より前に発行される公開信頼TLSサーバー証明書の有効期間は最大200日です。実際の期限には発行元が設定した notAfter を使います。発行日による上限なので、既発行証明書の終了日時が一律に書き換わるわけではありません。組織内PKIやSAML署名用の証明書は別の運用として管理します。

証明書台帳には、対象ホスト・終端・発行元・実際の有効期限・管理者・代行窓口をそろえます。通知の間隔は、短い有効期間や休日でも更新と確認が間に合うように決めます。自動更新のアラートに加え、利用経路ごとの提示期限を監視すると、発行後の配置漏れも見つけやすくなります。

関連用語・関連ページ

• TLS、PKI、ACMEで、暗号化・証明書の信頼・発行自動化の役割を確認する。
• TLSとSSLの違いで、証明書の更新と通信プロトコルの設定を区別する。
• インターネット公開管理画面のチェックリストで、証明書の設定を変更する管理面の公開範囲と責任者を確認する。
• 秘密鍵の露出が疑われる場合は、TLS秘密鍵漏えい時の初動対応と漏えい疑い初動テンプレートへ進む。
• プロトコルの用語クイズで、復旧対応に出てきた用語を復習する。

公式情報・参考情報

• IETF RFC 5280 §4.1.2.5 Certificate Validity — 証明書の利用開始日時・終了日時。
• Chromium ネットワークエラーの定義 — 日付・名前・信頼のエラーの区別。
• Cloudflare Error 525 — CDNとオリジン間のTLSハンドシェイク失敗。
• Cloudflare Error 526 — Full (strict)のWebサイトでのオリジン証明書検証。
• Certbot User Guide — Renewing certificates — 更新対象がない場合の正常終了と、更新後の処理の区別。
• CA/Browser Forum TLS Baseline Requirements §6.3.2 — 発行日ごとの公開信頼TLS証明書の有効期間の上限。