TLS証明書の秘密鍵が漏えいした時の初動対応：失効・再発行・影響確認

冒頭要約

WebサーバーやCDNで使うTLS証明書の秘密鍵が、Gitリポジトリ、バックアップ、共有ストレージ、CI/CDログ、端末などへ露出した疑いがある場合、ファイルを削除したり証明書を更新したりするだけでは対応完了になりません。第三者が秘密鍵を取得した可能性を前提に、旧証明書を失効できる状態まで進める必要があります。

最初に、対象証明書のシリアル番号またはフィンガープリント、ドメイン名、秘密鍵の配置先、発見時刻、露出範囲を記録します。続いて、信頼できる環境で新しい鍵ペアを生成し、新しい証明書を発行・配置してから、旧証明書を認証局（CA）の公式手続きで失効させます。

この記事では、Web担当者、開発者・SRE、情シス、SaaS管理者、CSIRTが、検知後の最初の15分、失効と再発行、全配置先の切り替え、影響確認、エスカレーションへ進む順番を整理します。秘密鍵を実行して確かめる手順や、悪用方法は扱いません。

---

TLS証明書の秘密鍵とは

TLS証明書は、Webサイトのドメイン名と公開鍵などを認証局が結び付けた公開情報です。ブラウザへ送られる証明書そのものは秘密ではありません。一方、対応する秘密鍵はサーバー側だけで保護すべき秘密情報です。

対象	役割	漏えい時の考え方
公開証明書	ドメイン名、公開鍵、発行者、有効期間などをブラウザへ示す	公開される前提。証明書だけを見つけても、秘密鍵漏えいとは限らない
秘密鍵	サーバーが正当な証明書の管理者であることを暗号学的に示す	第三者が取得した可能性があれば、新しい鍵ペアへの交換と旧証明書の失効が必要
CAアカウント	証明書の発行・再発行・失効を管理する	アカウント侵害も疑われる場合は、認証情報、MFA、監査ログ、委任権限を確認する
DNS・ドメイン管理	ドメイン所有確認や通信先の制御に関係する	不審なDNS変更やドメイン管理者追加があれば、秘密鍵漏えいより広い侵害として扱う

秘密鍵の漏えいと、CAアカウントやDNSの侵害は同じ事象ではありません。ただし同じ端末、CI/CD、パスワード保管庫から複数の認証情報が露出した場合は、まとめて影響範囲を確認する必要があります。

PKIやデジタル署名を先に整理したい場合は、用語ページと暗号技術の基礎を参照してください。

---

読者別の影響：誰が何を確認するか

読者	最初に確認すること	主な責任範囲
Web担当者・サイト管理者	対象ドメイン、CDN・WAF・ホスティング、証明書管理画面	利用サービスの特定、所有者への連絡、切り替え後の表示確認
開発者・SRE	Webサーバー、ロードバランサー、Ingress、Secret Store、CI/CD	新しい鍵ペアの生成、証明書配置、旧鍵削除、ログ・構成確認
情シス・SaaS管理者	CAアカウント、DNS、共有保管庫、委託先、更新担当	失効申請、アカウント保護、全配置先の棚卸し、再発防止
CSIRT・SOC	検知経路、露出期間、証跡、異常通信、他の秘密情報	優先度判断、調査範囲、証拠保全、経営・法務への連携
サービス責任者	停止許容時間、顧客影響、委託先、告知・契約要件	緊急変更の承認、業務影響判断、関係者への報告

マネージド証明書では、利用者が秘密鍵をエクスポートできない場合があります。その場合、「秘密鍵ファイルが漏れた」と決めつけず、CA・クラウドアカウント、証明書発行権限、DNS設定、監査ログの侵害可能性を確認します。

---

まず確認すること：最初の15分チェックリスト

1. 発見した事実を記録する

• 発見日時、発見者、通知元、インシデント番号を記録する。
• 秘密鍵が見つかった場所と、閲覧できた人・システムの範囲を記録する。
• Public、社内限定、特定メンバー限定など、露出範囲を区別する。
• ファイル削除、権限変更、リポジトリ非公開化など、すでに実施した操作を時系列で残す。
• 秘密鍵そのものではなく、ファイル名、保存場所、ハッシュ値、検知元の参照情報を記録する。

公開リポジトリや不特定多数が閲覧できる場所に露出した場合は、ダウンロード履歴の有無だけで安全と判断せず、取得された可能性があるものとして優先度を上げます。

2. 対象証明書を特定する

• 証明書のシリアル番号またはフィンガープリント。
• 対象ドメインとSubject Alternative Name（SAN）。
• 発行した認証局、証明書管理アカウント、発行日時、有効期限。
• 本番、検証、開発のどの環境で使われているか。
• ワイルドカード証明書や複数ドメイン証明書か。
• 同じ秘密鍵を別の証明書や別環境で再利用していないか。

秘密鍵ファイルの名前だけで対象を決めないでください。構成管理、証明書管理画面、公開証明書の情報を突き合わせ、どの証明書と組み合わされているかを確認します。

3. 配置先と所有者を洗い出す

• CDN、WAF、ロードバランサー、API Gateway、リバースプロキシ。
• Webサーバー、メールサーバー、VPN、監視・管理画面。
• Kubernetes Ingress、コンテナ、VM、サーバーレス環境。
• Secret Store、構成管理、CI/CD、ビルド成果物、コンテナイメージ。
• バックアップ、スナップショット、旧サーバー、災害復旧環境。
• 委託先、SaaS、ホスティング会社、証明書更新代行サービス。

一つのWebサーバーで見つかっても、そこだけを交換して終えてはいけません。エッジ、待機系、旧環境、バックアップを含む全配置先を一覧にします。

4. 新しい鍵ペアと証明書を準備する

• 信頼できる端末または鍵管理サービスで、新しい鍵ペアを生成する。
• 漏えいが疑われる秘密鍵を再利用しない。
• 新しい鍵ペアに対して証明書を発行する。
• 対象ドメイン、SAN、有効期限、発行元、鍵の保管先を確認する。
• 緊急変更の承認者、作業者、ロールバック条件を決める。

秘密鍵が漏れた疑いがある場合、同じ秘密鍵を使った「再発行」では問題を解消できません。必ず新しい鍵ペアを使います。

5. 証拠と周辺ログを保全する

• 検知通知、リポジトリ履歴、共有設定、ファイル監査ログ。
• CDN、WAF、ロードバランサー、Webサーバーのアクセスログ。
• CAアカウントのログイン、証明書発行・失効、管理者変更の履歴。
• DNSレコード、ネームサーバー、ドメイン管理者の変更履歴。
• Secret Store、CI/CD、クラウドIAM、端末の監査ログ。
• Certificate Transparencyで確認した想定外の証明書発行。

証跡を壊さない記録方法は、インシデント時の証拠保全に沿って統一します。

---

初動対応：やること、やらないこと、記録すること

やること

1. 対象証明書、秘密鍵、全配置先、所有者を特定する。
2. 信頼できる環境で新しい鍵ペアを生成し、新しい証明書を発行する。
3. CDN、ロードバランサー、Webサーバーなど全配置先を新しい証明書へ切り替える。
4. 外部と内部の双方から、対象ホスト名、証明書チェーン、有効期限、主要な業務通信を確認する。
5. 旧証明書をCAの公式手続きに沿って失効させ、実施時刻と理由を記録する。
6. 旧秘密鍵をSecret Store、CI/CD、サーバー、バックアップなどから削除または隔離する。
7. CAアカウント、DNS、IAM、ログ、同時に露出した他のsecretを確認する。

失効前に新しい証明書へ切り替えるのは、正規サービスを継続しながら旧証明書を無効化するためです。ただし不正利用が進行している、または切り替えを待つリスクが高い場合は、サービス責任者とCSIRTが一時停止を含めて判断します。

やってはいけないこと

• 漏えいした秘密鍵を使い、有効性や接続可否を試さない。
• 秘密鍵をチケット、チャット、メール、オンライン解析サービスへ貼り付けない。
• 新しい証明書を発行しただけで、旧証明書の失効を省略しない。
• 同じ秘密鍵を使い回して再発行しない。
• 一つのWebサーバーだけ交換し、CDNや待機系の旧鍵を残さない。
• 記録を残さずにリポジトリ履歴、ログ、サーバー、CAアカウントを削除しない。
• 不審なアクセスが見つからないことを、秘密鍵が取得されていない証明にしない。
• テストを省略して、本番の全エンドポイントを一斉に切り替えない。

記録すること

• 証明書のシリアル番号、フィンガープリント、対象ドメイン、SAN、発行元。
• 秘密鍵の保管場所、配置先、所有者、作成・配布方法。
• 発見、封じ込め、再発行、切り替え、失効、旧鍵削除、復旧の各時刻。
• 露出場所、閲覧範囲、露出開始時刻、公開状態の確認結果。
• 新旧証明書の配置先ごとの切り替え結果と確認者。
• CA、DNS、IAM、Web、CDN、WAF、CI/CDで確認したログの期間と結果。
• 未確認事項、顧客・業務への影響、エスカレーション先、次の判断期限。

---

失効・再発行・更新の違い

操作	主な目的	旧証明書への影響	秘密鍵漏えい時の位置付け
更新	有効期限が近い証明書を次の証明書へ切り替える	旧証明書は有効期限または失効まで利用できる	定期運用。漏えい対応では失効を別途実施する
再発行	証明書の内容や鍵を変更して新しい証明書を得る	通常、旧証明書が自動で無効になるとは限らない	新しい鍵ペアで実施し、旧証明書の失効へ進む
失効	有効期限前の証明書を信頼対象から外す	CAの失効情報へ反映される	旧秘密鍵を第三者が使える可能性を残さないために必要
旧鍵削除	組織内の配置先から秘密鍵を除去する	CA側の証明書状態は変わらない	失効と別に、サーバー・保管庫・バックアップで実施する

RFC 5280では、秘密鍵が侵害されたと考えられる場合の失効理由としてkeyCompromiseが定義されています。実際の申請方法や選択肢は認証局ごとに異なるため、利用中のCAが提供する公式手続きに従います。

---

影響確認：どこまで調べるか

1. 秘密鍵が取得できた範囲

• Publicリポジトリ、公開URL、誰でも参加できるチャットに露出したか。
• 社内リポジトリ、共有ドライブ、チケットで閲覧権限が広がっていなかったか。
• CI/CDログ、ビルド成果物、コンテナイメージ、バックアップに複製されていないか。
• 端末のマルウェア感染、退職者アクセス、委託先アカウントの侵害が疑われないか。

露出期間を確定できない場合は、最後に安全を確認できた時点、秘密鍵の作成日、ログ保存期間を基準に調査範囲を決めます。「ダウンロード記録がない」は、取得されていないことの十分な証明にならない場合があります。

2. CA・DNS・管理アカウントの変化

• 想定外の証明書発行、再発行、失効、連絡先変更。
• CAアカウントの新しい管理者、APIトークン、MFA変更。
• DNSレコード、ネームサーバー、ドメインロック、登録者情報の変更。
• クラウドIAM、Secret Store、CI/CDの権限変更。
• 通知メールの転送、削除、宛先変更。

想定外の証明書発行はCertificate Transparencyの情報も手掛かりになります。ただしログで証明書を見つけただけでは、不正発行と断定できません。組織の証明書台帳、CAアカウント、発行担当者と照合します。

3. 通信・サーバー・アプリケーションの変化

• 通常と異なる送信元、地域、時間帯、ユーザーエージェント。
• CDN、WAF、ロードバランサー、Webサーバーの構成変更。
• 認証エラー、証明書警告、接続先変更、DNS解決先の変化。
• 管理画面、API、顧客ポータルでの不審なログインやセッション。
• ログ設定の無効化、保存先変更、欠損、時刻の不整合。

秘密鍵漏えいだけで、Webサーバー侵害や過去通信の復号を断定してはいけません。TLSの暗号スイート、鍵交換方式、サーバー構成、通信の取得状況によって影響は異なります。確認できた事実と、可能性として残る事項を分けて報告します。

---

判断基準：危険度とエスカレーション条件

優先度	条件	推奨する判断
緊急	公開場所へ露出、第三者取得の痕跡、想定外の証明書発行、DNS・CAアカウント変更がある	即時に新しい鍵へ切り替え、旧証明書を失効し、CSIRT・責任者を招集する
緊急	認証、決済、個人情報、管理画面、APIなど重要サービスの証明書である	顧客・法務・契約上の影響を含めて判断し、監視と証拠保全を強化する
高	ワイルドカード、複数ドメイン、複数環境で同じ鍵を利用している	影響する全ドメイン・全配置先を対象に交換し、再利用の範囲を調査する
高	露出期間、配置先、所有者、閲覧範囲のいずれかが不明	不明点を安全の根拠にせず、失効と全量棚卸しを優先する
中	閲覧範囲が限定され、全配置先を特定でき、不審な変更が確認されていない	鍵交換・失効・記録を完了し、保管と配布方法を改善する
低	ダミー鍵、未使用鍵、または実環境に対応しないことを複数の情報で確認できた	判断根拠を記録し、誤配置と検知ルールを改善する

次のいずれかに当てはまれば、Web担当者や開発者だけで閉じずにエスカレーションします。

• 顧客・従業員情報、決済、医療、契約上の機密を扱うサービスに関係する。
• CAアカウント、DNS、クラウドIAM、CI/CDの侵害が疑われる。
• 秘密鍵と同じ場所からAPIキー、パスワード、署名鍵なども見つかった。
• 影響するドメイン、配置先、露出期間、閲覧範囲を確定できない。
• 不審な証明書発行、設定変更、認証、通信、ログ欠損がある。
• 委託先、取引先、複数の組織・サービスへ影響する。
• サービス停止リスクと封じ込めの優先度が衝突している。

---

復旧確認と記録テンプレート

復旧は「トップページが開いた」だけでは完了しません。次の項目を配置先ごとに確認します。

• 対象ドメインとSANが正しい。
• 新しい証明書と中間証明書のチェーンが正しい。
• CDN、ロードバランサー、Webサーバー、待機系が新しい証明書を返している。
• API、モバイルアプリ、SaaS連携、監視、バッチが正常に接続できる。
• 旧証明書が失効済みで、旧秘密鍵が全配置先から除去されている。
• CA・DNS・IAM・アクセスログの確認結果と未確認事項が記録されている。
• 証明書台帳、所有者、更新通知、保管・配布手順が更新されている。

インシデント番号:
発見日時・発見者:
検知元・露出場所:
閲覧可能だった範囲:
対象ドメイン・SAN:
旧証明書のシリアル番号 / フィンガープリント:
発行元CA・証明書管理アカウント:
秘密鍵の配置先・所有者:
新しい鍵ペアの生成場所:
新証明書の発行日時:
配置先ごとの切り替え結果:
旧証明書の失効日時・実施者・理由:
旧秘密鍵の削除 / 隔離結果:
CA・DNS・IAM・アクセスログの確認期間:
不審な事象:
顧客・業務への影響:
未確認事項:
エスカレーション先・判断者:
次回確認日時:

---

よくある誤解

「証明書は公開されているので、秘密鍵も公開情報である」

誤りです。ブラウザへ配布される公開証明書と、サーバー側で保護する秘密鍵は別物です。公開証明書を見つけただけでは事故ではありませんが、対応する秘密鍵が露出した疑いはインシデントとして扱います。

「新しい証明書を発行すれば、旧証明書も自動的に無効になる」

必ずしもそうではありません。新しい証明書の発行・配置と、旧証明書の失効は別の作業です。CAの管理画面や公式窓口で旧証明書の状態を確認します。

「同じ秘密鍵で再発行すれば、証明書番号が変わるので安全になる」

誤りです。第三者が秘密鍵を取得した可能性は残ります。漏えい対応では、信頼できる環境で新しい鍵ペアを生成します。

「秘密鍵が漏れたら、過去のTLS通信はすべて復号された」

断定できません。暗号スイート、鍵交換方式、通信の取得状況などで影響は異なります。一方で、影響が確認できないことを理由に鍵交換や失効を省略してはいけません。

「アクセスログに異常がなければ、安全である」

ログの種類、保存期間、CDN・WAF・ロードバランサーの構成、攻撃者が残す痕跡には限界があります。CA、DNS、IAM、構成変更、証明書発行履歴を含めて確認し、「異常なし」と「確認できない」を分けます。

---

関連用語・関連ページ

目的	ページ
用語を確認する	TLS、PKI、デジタル署名、Certificate Transparency、OCSP Stapling、Secrets Management
初動対応を実務へ落とす	情報漏えい疑い初動テンプレート、GitHub Secret漏えいチェックリスト
方式の違いを整理する	TLSとSSLの違い、共通鍵暗号と公開鍵暗号の違い
基礎から学ぶ	HTTPSとTLS、暗号技術の基礎
関連する初動対応を読む	サービスアカウントキー漏えい時の初動対応、SAML・SSO証明書更新チェックリスト、インシデント時の証拠保全
知識を確認する	セキュリティクイズ

---

公式情報・参考情報

• Let’s Encrypt: Revoking Certificates - 証明書を安全でないと判断した場合の失効方法と、秘密鍵侵害を理由とする失効の考え方を確認できる。
• CA/Browser Forum: Baseline Requirements for TLS Server Certificates - 公開TLSサーバー証明書の発行、管理、失効に関する認証局向け要件を確認できる。
• IETF RFC 5280: Internet X.509 PKI Certificate and CRL Profile - X.509証明書、CRL、失効理由keyCompromiseの標準仕様を確認できる。
• NIST SP 800-57 Part 1 Rev. 5: Recommendation for Key Management - 暗号鍵のライフサイクル、保護、侵害時の管理を整理する指針。
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations - インシデント対応を組織のサイバーセキュリティリスク管理へ組み込むための指針。
• OWASP Cheat Sheet: Transport Layer Security - TLSの安全な構成と秘密鍵保護の実装観点を確認できる。
• OWASP Cheat Sheet: Secrets Management - 秘密情報の作成、保管、ローテーション、失効、廃棄をライフサイクルで管理する指針。
• IETF RFC 9162: Certificate Transparency Version 2.0 - TLS証明書の発行を監査可能なログへ記録するCertificate Transparencyの標準仕様。

---

まとめ

TLS証明書の秘密鍵が漏えいした疑いがある場合は、公開証明書と秘密鍵を区別し、対象証明書、全配置先、露出範囲を最初に記録します。その後、信頼できる環境で新しい鍵ペアを生成し、新証明書を全配置先へ反映してから、旧証明書の失効と旧秘密鍵の除去を完了します。

「再発行したから旧証明書も無効」「ログに異常がないから安全」とは判断できません。CAアカウント、DNS、IAM、Certificate Transparency、アクセスログ、同時に露出した他のsecretを確認し、判明した事実と未確認事項を分けて報告します。

実作業を始める場合は、情報漏えい疑い初動テンプレートへ記録を移し、配置先の確認にはGitHub Secret漏えいチェックリストの保管場所・履歴確認も併用してください。