Certificate Transparencyログの監視方法｜意図しないSSL証明書発行を検知する運用

自社ドメインの証明書が発行されたという通知を受けても、直ちに不正発行とは限りません。CDNの自動更新、制作会社による切り替え、検証環境への追加など、正規の作業でも新しい証明書が発行されます。一方、担当者が知らないからと通知を放置すると、DNSや認証用アカウントの侵害を見逃すおそれがあります。

Certificate Transparency（CT）ログ監視は、自社ドメインを含む証明書・事前証明書の記録を検知し、発行元、対象名、有効期間、申請履歴を正規の運用台帳と照合する仕組みです。通知の受信だけで終わらせず、正常・要確認・緊急調査の判定、担当者への引き継ぎ、認証局への連絡まで決めます。SSL証明書という呼称が一般的ですが、ここで扱うのは公開Webサイトなどで使うTLSサーバー証明書です。

CT監視が機能していると言えるのは、通知を受け取れた時ではなく、発行の正当性を説明でき、説明できない証明書を担当者と期限付きで調査へ渡せた時です。

---

本記事のポイント

1. CT通知だけで不正発行と判断せず、対象名・発行元・有効期間と、利用サービス・変更履歴を照合します。
2. CAAによる発行先制限、配信中の証明書の期限監視、CTの発行記録監視を組み合わせて運用します。
3. 説明できない発行には担当者と確認期限を付け、認証局への連絡と認証経路の調査まで追跡します。

---

CTログで分かることと、別の監視が必要なこと

CTは証明書の発行を公開ログで確認できるようにする仕組みです。CTプロジェクトの公式解説では、ログは追記型であり、監視者が証明書や事前証明書の登録を調べる役割を説明しています。登録済みの情報を後から消して、発行がなかったことにする運用ではありません。

事前証明書は、最終的な証明書が利用者へ渡る前にCTへの登録を進めるためのものです。同じ発行に由来する情報が複数のログで見つかったり、事前証明書と最終証明書が別の記録として見えたりします。そのため、通知件数をそのまま「攻撃件数」や「新しいサイトの数」に置き換えないことが大切です。

確認したいこと	CTで得られる手掛かり	追加で必要な確認
自社名を含む証明書の発行	対象ドメイン名、発行元、有効期間など	申請者、利用サービス、変更承認との照合
現在サイトが提示している証明書	候補となる証明書の履歴	対象ホストへのTLS接続と配信拠点ごとの確認
秘密鍵が漏えいしていないか	予期しない発行の存在	秘密鍵保管先、アカウント、DNS・サーバーログの調査
証明書の期限が近いか	ログに記録された有効期間	実際に配信中の証明書に対する期限監視
発行そのものを制限したい	発行後の検知と照合	CAA、ドメイン認証、アカウントの保護

CTに載っていることは、その証明書を自社が承認したことや、現在のサイトで使用していることの証明ではありません。また、CTログ自体が不正発行を止めたり、秘密鍵を保護したりするわけでもありません。RFC 9162はCT Version 2.0を記述する実験的仕様であり、現行の全サービスが同じバージョンのAPIを採用していると考えて実装しないようにします。

監視対象も公開Web PKIを中心に考えます。社内認証局だけで発行する証明書や、そもそも利用する監視サービスが収集していないログの情報まで、漏れなく検知できるとは限りません。Web運用全体の担当分担が曖昧なら、まずウェブサイト構築と運用の基本から、ドメイン・DNS・CDN・証明書の管理者を分けて整理します。

監視対象と正規発行台帳を先に整える

最初に監視するのは、本番サイトだけではありません。企業が保有するルートドメイン、サービス用サブドメイン、採用・イベント・キャンペーン用ドメインを列挙し、管理責任者、DNSの管理先、証明書を自動発行するサービスを結び付けます。廃止したサイトでもドメインを保有している場合は、監視を外す理由を確認します。

検索条件の末尾一致にも注意が必要です。たとえばexample.comを対象にするとき、notexample.comのような別ドメインを混ぜず、example.com自身と、その下の名前を区切り位置を含めて判定します。ワイルドカード名を含む証明書や、複数のSAN（Subject Alternative Name）を持つ証明書も確認対象です。ツールの「サブドメインを含む」という設定が何を意味するかは、実データで確かめます。

正規発行台帳には、少なくとも対象ドメイン、利用サービス、発行元認証局、申請・更新を実行するアカウントの管理責任者、変更チケット、有効期間、証明書を特定する値を残します。証明書のDERバイト列のSHA-256フィンガープリントと、発行元・シリアル番号は混同せず、記録の種類を明示します。秘密鍵や認証用トークンを台帳へ貼り付ける必要はありません。

CDNやホスティング事業者が認証局を変更する場合があります。「いつもの認証局だから正常」「別の認証局だから侵害」と単独で決めず、サービス側の更新履歴と申請記録を確認できる状態にします。自動更新で毎回通知が出る場合も、発行元名だけを永久に除外するより、対象サービス、ドメイン、更新の根拠、例外の有効期限をセットで管理するほうが誤検知と見逃しを抑えられます。

CAAは発行を許可する認証局をDNSで示す仕組みです。RFC 8659に基づく発行時の制御と、CTによる発行記録の監視は役割が異なります。CAAを設定しても過去の証明書を失効させることにはならず、CT監視も不要にはなりません。設定変更の手順はCAAレコードによる証明書発行先の制限で確認できます。

検知から照合・調査までを7段階で回す

運用の読み順は、対象の登録、ログの検知、正規発行との照合、未確認の調査、必要な初動対応です。以下の図は、この順番と、調査結果を台帳へ戻す関係を示します。通知から直接失効へ飛ばず、証明書の特定と担当者への確認を挟みます。

1. 対象範囲と窓口を登録する。ルートドメインとサブドメインの包含条件、監視担当者、代替担当者、証明書管理者を決めます。組織変更時にも窓口が更新されるよう、個人の受信箱だけで完結させない構成にします。
2. 監視サービスの収集範囲を確認する。対応ログ、履歴検索の期間、通知遅延、検索条件、障害時の再取得、出力形式を確認します。ログに記録されるまでの時間と、監視サービスが通知するまでの時間は別です。「発行直後に必ず届く」という前提では初動期限を設計しません。
3. 初回の履歴を基準化する。既存の記録を取り込み、正常な自動更新や廃止サービスを整理します。初回検出をすべて新規異常と扱うと確認が埋もれますが、古い記録だから安全とみなすことも避け、基準化を完了した日時と範囲を記録します。
4. 通知を正規化して重複をまとめる。検出時刻、ログへの登録時刻、有効期間を別々の項目にします。同一証明書の複数ログ登録はまとめつつ、ログ名と元の記録を保持します。事前証明書と最終証明書はバイト列が異なるため、ハッシュ一致だけで一つにまとめる設計にはしません。
5. 申請履歴と突き合わせる。対象名、発行元、有効期間、利用サービス、変更チケットを照合します。制作会社やCDNが更新した場合は、その担当者へ証明書を特定できる情報を添えて確認します。通知メール中のリンクから認証情報を入力せず、既知の管理画面や連絡先を使います。
6. 未確認の通知に期限を付ける。「正常確認済み」「所有部門へ確認中」「緊急調査」の状態を分け、担当者、次の確認時刻、保留理由を残します。重要な顧客向けドメイン、管理者が発行を否定したもの、DNS変更と時刻が重なるものは、通常の自動更新より優先度を上げます。
7. 監視自体を点検する。承認済みの定期更新を使い、発行記録が検知され、担当者へ通知され、対応記録が残るか確認します。通知がない日を正常稼働の証拠にせず、収集処理の最終成功時刻、取得位置、エラー件数、未確認件数を監視します。

たとえば、担当者が知らない証明書を午前中に検出し、SANに自社の採用サイト名が含まれていたとします。台帳には制作会社が管理するCDNがあり、変更履歴から前夜の自動更新を確認でき、発行元・対象名も一致したなら、根拠を付けて正常に分類できます。反対に管理者全員が発行を否定し、同時刻にDNSの管理者変更が見つかったなら、CTの追加検索だけを続けずインシデント対応へ引き継ぎます。

運用上の期限は、組織の対応体制と重要度に合わせて決めるものです。平日の翌営業日確認で足りるドメインと、夜間も連絡すべきログイン用ドメインを同じ一律期限にしないようにします。DNSを移行した直後は証明書の正規更新も増えるため、権威DNS移行の変更記録を照合材料にすると、理由の分からない例外を減らせます。

不審な発行を見つけた後の初動と完了条件

最初に、対象名、発行元、シリアル番号、フィンガープリント、ログの参照先、検出時刻、確認した担当者を保存します。通知のスクリーンショットだけでは同じ証明書を特定しにくいため、取得可能な証明書やログ記録も残します。秘密鍵をメールで集めたり、不審な通知を調べるために本番設定を次々に変更したりしないようにします。

正規の発行でない疑いが残る場合は、認証局の公式窓口と、DNS・ホスティング・CDNの管理責任者へ連絡します。調べる対象は証明書だけでなく、ドメイン認証に使えるDNS API、ACMEアカウント、HTTP上の認証ファイル、委託先アカウントの変更履歴です。証明書の不正発行と秘密鍵の漏えいは同義ではないため、どちらが確認でき、どちらが未確認かを区別します。

失効が必要な場合は、発行した認証局の要件に従います。Let’s Encryptの公式失効手順では、発行アカウント、別の認証済みアカウント、証明書の秘密鍵などによる権限確認を説明しています。別の認証局で同じ操作ができるとは限りません。自分たちが発行していない証明書でも、必要な証拠と確認方法を認証局へ相談します。

正常に利用中の証明書まで誤って失効すると、サイトの接続に影響します。対象証明書を特定し、正規サービスへの影響と代替証明書の展開手順を確認します。ただし、侵害が確認された場合はサービス継続だけを理由に対応を先送りせず、責任者が封じ込めの優先順位を決めます。侵害された認証経路を残したまま証明書だけ失効しても、再発行されるおそれがあります。

完了条件は「CT通知を閉じた」だけでは不十分です。正規発行なら裏付けとなる履歴と台帳更新、不正の疑いがあれば認証局への連絡、必要な失効、認証経路の保護、正規サイトの接続確認まで記録します。失効後もCTの記録は残るため、同じ証明書の再通知は対応履歴へ紐付けます。ブラウザ等への失効情報の反映も一律に即時とは断定せず、使用環境の確認を続けます。

月次の振り返りでは、通知数だけでなく、確認までの時間、所有部門不明の件数、期限超過、監視停止時間、例外の期限切れを確認します。CTの仕様確認にはRFC 9162を参照しつつ、実装するログや監視製品の現行仕様を別途確かめます。特定製品の対応範囲や料金に依存しない運用手順として、2026年9月7日時点の公式資料に基づき整理しています。

よくある質問

CT通知が届けば、不正な証明書発行が確定しますか？

確定しません。正規の自動更新やCDN側の発行も検知されます。発行元と対象名だけでなく、利用サービスと変更履歴を照合して判断します。

CT監視だけで証明書の更新忘れを防げますか？

防げません。ログにある証明書と現在配信中の証明書は一致するとは限りません。実際のTLS接続で提示される証明書の期限を別に監視します。

CAAを設定していればCT監視は不要ですか？

不要にはなりません。CAAは認証局による発行時の確認、CTは発行記録の可視化と検知を担います。過去の発行や設定変更の影響を確認するため、組み合わせて運用します。

同じ証明書の通知が何度も届くのはなぜですか？

複数ログへの登録や、事前証明書と最終証明書の違いなどが考えられます。元の記録を保持し、同一証明書の重複と関連する別記録を区別して整理します。

失効した証明書をCTログから削除できますか？

CTは追記型の公開ログなので、失効後も発行の記録は残ります。削除で通知を止めるのではなく、証明書を特定して失効・調査履歴と関連付けます。

監視通知が来ない日は安全と判断できますか？

判断できません。収集範囲外の記録や通知障害の可能性があります。最終取得時刻、エラー、通知経路を確認し、承認済みの更新で定期的に検知を試します。