auditing-tls-certificate-transparency-logs

TLS 証明書透明性ログの監査

使用する場面

• 所有ドメインについて、未知の認証局による未許可または予期しない証明書発行を監視する場合
• 公開 CT ログに記録された証明書を通じて、サブドメインや隠れたサービスを発見する場合
• 類似ドメインの証明書を使用するフィッシングインフラ（タイポスクワッティング、ホモグラフ攻撃）を検出する場合
• 発行されたすべての証明書がブラウザーポリシーで義務付けられたとおり CT ログに記録されていることを確認し、認証局のコンプライアンスを監査する場合
• 新たな証明書発行を検知するアラート機能を備えた、継続的な証明書監視をセキュリティ運用パイプラインに組み込む場合

使用しないでください。認証局への攻撃や妨害、レート制限や利用規約に違反する CT ログのスクレイピング、または DNS 検証で結果を裏付けることなくサブドメイン列挙の唯一の手段として使用すること。

前提条件

• requests、cryptography、pyOpenSSL ライブラリをインストールした Python 3.10+
• crt.sh（HTTPS）および公開 CT ログサーバーへのネットワークアクセス
• 監視するドメインの一覧（所有ドメイン、ブランド名のバリエーション、タイポスクワッティング候補）
• 新しい証明書の発見を通知するための SMTP 認証情報または Webhook URL
• X.509 証明書の構造と TLS 証明書チェーンの検証に関する基本的な理解

ワークフロー

ステップ 1：ドメインの一覧作成とベースライン

監視対象ドメインの初期証明書インベントリを作成します。

• 監視範囲を定義する：所有するすべてのルートドメイン、登録済みブランド名、既知の子会社を一覧にします。サブドメインを網羅的にカバーするため、ワイルドカードパターン（%.example.com）も含めます。
• crt.sh に問い合わせて過去の証明書を取得する：crt.sh の JSON API を使用して、各ドメインの既知の証明書をすべて取得します。API エンドポイント https://crt.sh/?q=%.example.com&output=json は、ワイルドカードパターンに一致する証明書を返します。フィールドには issuer_ca_id、issuer_name、common_name、name_value、not_before、not_after、serial_number などが含まれます。
• ベースラインデータベースを作成する：初期の証明書セットをローカルの SQLite データベースに保存します。列には証明書 ID、ドメイン、発行者、有効期間、SAN（サブジェクト別名）、初回確認時刻を含めます。このベースラインにより、すでに把握している証明書に対するアラートを防止できます。
• 許可済みの認証局を特定する：ベースラインから、ドメインの証明書を正当に発行した認証局の一覧を抽出します。この一覧にない認証局による今後の発行は、高優先度のアラートを発生させます。
• サブドメインを整理する：すべての証明書の name_value フィールドから、一意なサブドメインをすべて抽出し、初期のサブドメインインベントリを作成します。

ステップ 2：CT ログの継続的な監視

新たに発行される証明書を継続的に監視するよう設定します。

• crt.sh を定期的にポーリングする：crt.sh API に一定の間隔（15～60 分ごと）でクエリを送り、新しい証明書を確認します。現在有効な証明書に絞るには、exclude=expired パラメーターを使用します。結果をベースラインデータベースと比較し、新しいエントリーを特定します。
• 証明書の詳細を解析する：新しい証明書ごとに、SAN の全リスト、発行者チェーン、有効期間、鍵の種類とサイズ、CT ログの SCT（署名済み証明書タイムスタンプ）の詳細、証明書のフィンガープリント（SHA-256）を抽出します。
• プレ証明書を検出する：CT ログには、最終発行前に送信されたプレ証明書（毒入れされた証明書）が含まれます。証明書がまもなく発行されることを示す早期警告となるため、まだ有効になっていない可能性があっても追跡します。
• CT ログの Signed Tree Head（STH）を監視する：高度な監視を行う場合は、CT ログサーバーに直接クエリを送り、最新の STH を取得して、連続するツリーヘッド間の一貫性証明を検証します。一貫性がない場合は、ログの不正動作（スプリットビュー攻撃）を示しています。
• レート制限に注意する：クエリの間隔を空け、応答をキャッシュして、crt.sh のレート制限を遵守します。HTTP 429 応答を受け取った場合は、指数バックオフを実装します。大量の監視を行う場合は、crt.sh:5432 の crt.sh PostgreSQL インターフェースへの直接クエリを検討してください。
• Atom/RSS フィードの代替案：より軽量な監視には、crt.sh の Atom フィードを購読します。https://crt.sh/atom?q=%25.example.com を使うと、新しいログエントリーの通知をリアルタイムで受け取れます。

ステップ 3：CT データによるサブドメインの発見

証明書の透明性データからサブドメインを抽出し、検証します。

• ワイルドカードの展開：ワイルドカード SAN（*.dev.example.com）を含む証明書から、DNS ゾーンファイルに記載されていない可能性のあるサブドメインの存在が明らかになります。親ドメインを、以降の列挙対象として記録します。
• 過去の証明書の調査：exclude=expired パラメーターを指定せずに crt.sh にクエリを送り、期限切れの証明書に含まれる、現在も DNS で名前解決できる可能性のあるサブドメインを見つけます。こうしたサブドメインは、サブドメイン乗っ取りの脆弱性につながる可能性がある、過去のインフラを示しています。
• DNS 検証：発見した各サブドメインについて、DNS 名前解決（A、AAAA、CNAME レコード）を実行し、現在有効かどうかを確認します。既知の IP アドレス範囲と照合して、シャドー IT や未承認のサービスを特定します。
• タイポスクワッティングの検出：監視対象ドメインのバリエーション（ビットスクワッティング、ホモグラフ、文字の挿入、削除、入れ替え、キーボード上で隣接する文字への置換）を生成し、これらのバリエーションに対して発行された証明書がないか CT ログを検索します。タイポスクワッティングドメインの証明書は、フィッシングインフラの存在を強く示しています。
• 重複排除と情報の拡充：発見したサブドメインを正規化し（小文字に変換し、末尾のドットを削除）、重複を排除したうえで、WHOIS データ、IP ジオロケーション、HTTP レスポンスヘッダーの情報を追加し、調査の優先順位を決めます。

ステップ 4：証明書発行アラート

セキュリティ上重要な証明書イベントに対するアラートルールを設定します。

• 未承認 CA アラート：承認済み CA リストに含まれていない CA が証明書を発行したときに通知します。ドメインハイジャック、ドメイン検証のための BGP ハイジャック、または CA の侵害を示している可能性があるため、最優先のアラートです。
• 新規サブドメインアラート：証明書に、これまで確認されていないサブドメインを含む SAN があるときに通知します。シャドー IT の導入や未承認サービスを検出できます。
• ワイルドカード証明書アラート：新しいワイルドカード証明書が発行されたときに通知します。ワイルドカード証明書は侵害された場合の影響が広範囲に及び、その発行は厳格に管理する必要があるためです。
• 有効期間が短い証明書の異常：通常の証明書ライフサイクルから逸脱する、異常に短い有効期間（24 時間未満）の証明書が発行されたときに通知します。Let's Encrypt の悪用や自動化されたフィッシングインフラストラクチャを示している可能性があります。
• 有効期限の警告：CT ログデータの not_after フィールドに基づき、重要なサービスの証明書の有効期限が近づいたとき（30 日、14 日、7 日前）に通知します。
• アラートの配信：メール（SMTP）、Slack webhook、PagerDuty を介してアラートを送信するか、既存のセキュリティ監視と連携できる SIEM 互換の JSON ログ形式で書き込みます。

ステップ 5：CT ログの完全性検証とレポート

ログの完全性を検証し、コンプライアンスの証跡を作成します。

• Signed Tree Head（STH）の監視：get-sth API エンドポイントを介して、監視対象の各 CT ログから最新の STH を取得します。STH にはツリーサイズと署名付きタイムスタンプが含まれています。ログの公開鍵を使用して署名を検証します。
• 整合性証明の検証：連続する STH の取得の間に、get-sth-consistency を介して整合性証明を要求し、ログが追記専用の状態を保ち、エントリが変更または削除されていないことを検証します。
• 証明書インベントリレポート：監視対象ドメイン向けに発行されたすべての証明書の完全なインベントリを、発行者ごとに分類し、有効性の状態と鍵強度の指標とともに作成します。
• CA の多様性分析：組織向けの証明書を発行している CA の数を報告し、集約の機会と単一障害点を特定します。
• コンプライアンスの証跡：PCI-DSS、SOC 2、または同様のフレームワークの対象となる組織では、CT 監視ログが証明書ライフサイクル管理と未承認の発行の検出能力を示す証跡となります。

主な概念

用語	定義
Certificate Transparency（CT）	認証局に対し、発行したすべての証明書を公開監査可能な追記専用ログに記録することを義務付けるオープンフレームワーク（RFC 6962）です。これにより、ドメイン所有者は不正な証明書発行を検知できます。
Signed Certificate Timestamp（SCT）	証明書を Maximum Merge Delay（通常は24時間）以内に登録するという、CT ログからの約束です。ブラウザーが証明書を信頼するには、複数のログからの SCT が必要です。
Merkle Tree	CT ログで使用される暗号学的データ構造です。リーフノードは証明書のハッシュ、親ノードはその子ノードのハッシュであり、効率的な整合性証明と包含証明を可能にします。
Precertificate	最終的な発行前に CT ログへ送信される証明書です。TLS での使用を防ぎつつログ内の場所を確保する poison 拡張（OID 1.3.6.1.4.1.11129.2.4.3）を含みます。
crt.sh	Sectigo が運営する無料のウェブサービスです。主要なすべての CT ログから証明書を集約し、検索可能な PostgreSQL データベースに格納して、ウェブおよび API の両方からアクセスできるようにします。
サブドメインの乗っ取り	サブドメインの DNS レコードが廃止されたサービス（クラウドプロバイダー、CDN）を指しており、攻撃者がそのサービスを再取得できる脆弱性です。期限切れの CT 証明書を通じて発見できます。
Maximum Merge Delay（MMD）	CT ログが SCT を返した後、送信された証明書を Merkle tree に取り込むまでに許される最大時間（通常は24時間）です。
CAA レコード	ドメインの証明書発行を許可される認証局を指定する DNS Certification Authority Authorization レコードです。CT 監視により、CAA ポリシー違反を検知できます。

ツールとシステム

• crt.sh：主要な CT ログアグリゲーターです。https://crt.sh/?q=<query>&output=json で JSON API にアクセスでき、ワイルドカードクエリ、ID によるフィルタリング、証明書の詳細取得をサポートします。
• ct-woodpecker：Let's Encrypt のオープンソース CT ログ監視ツールです。Prometheus および Grafana と統合し、ログの健全性と整合性を運用監視できます。
• certspotter：新たに発行された証明書を監視して通知を送る、SSLMate の CT ログ監視ツールです。ホスト型サービスまたはセルフホスト可能なツールとして利用できます。
• Google Argon / Xenon / Icarus：Google が運営する CT ログで、最も広く使用されているログの一部です。それぞれのログ URL で RFC 6962 API を介してクエリできます。
• OpenSSL：証明書の詳細の解析、チェーンの検証、CT 監視を通じて取得した証明書からの SAN リストの抽出に使うコマンドラインツールです。

よくあるシナリオ

シナリオ：金融サービス企業における不正な証明書発行の検知

コンテキスト：銀行が主要ドメイン（bank.example.com）を監視していたところ、これまで利用したことのないCAが、DNSに存在しないサブドメイン secure-login.bank.example.com を対象とする証明書を発行したことを、CTログから発見しました。

アプローチ：

1. CT監視エージェントが、crt.shの結果から secure-login.bank.example.com を対象とする「FreeSSL CA」の新しい証明書を検知します。このCAは、許可されたCAのリスト（DigiCert、Sectigo）に含まれていません。
2. 許可されていないCAと新しいサブドメインの組み合わせでアラートが発報され、CTログへの記録から15分以内にセキュリティチームへエスカレーションされます。
3. 証明書を調査します。公開鍵を抽出し、ドメインの検証にHTTP-01とDNS-01のどちらのチャレンジが使われたか確認して、発行組織についてWHOISを照会します。
4. secure-login.bank.example.com のDNSを照会すると、銀行が利用していないホスティングプロバイダーのIPアドレスに解決され、攻撃者のインフラであることが確認されます。
5. インシデント対応を開始します。FreeSSL CAに証明書の失効を依頼し、ドメインの不正利用を報告して、そのIPをブロックリストに追加し、フィッシング対策チームに通知します。
6. CAA DNSレコード（bank.example.com. CAA 0 issue "digicert.com"）を設定し、今後、許可されていないCAが証明書を発行できないようにします。

注意点：

• ワイルドカードパターン（%.bank.example.com）を監視せず、サブドメインの証明書を見逃す
• 実際の証明書が発行される前にCTログに記録されるプレ証明書を無視し、早期警告のメリットを失う
• インシデント後、すべてのドメインでCAAレコードが適切に設定されていることを確認しない
• 許可された変更後にベースラインデータベースを更新せず、正当な証明書の更新に対して過剰にアラートを発報する

シナリオ：CTログのサブドメイン発見による攻撃対象領域のマッピング

コンテキスト：ペネトレーションテスターが、アクティブスキャンを行う前に、対象組織のインターネット公開サービスをマッピングする外部偵察の第一段階としてCTログを利用します。

アプローチ：

1. %.target.com と既知のすべての子会社ドメインを対象にcrt.shを照会し、8年間にわたる2,400件の固有の証明書を収集します。
2. 有効期限切れの証明書も含め、すべての証明書のSANフィールドから347件の固有のサブドメインを抽出します。
3. 347件すべてのサブドメインのDNSを解決し、A/AAAAレコードがある現在稼働中のサブドメインを189件特定します。
4. 廃止されたクラウドサービス（S3バケットやAzureエンドポイントを指すCNAME）を指すサブドメインを12件特定します。これらはサブドメイン乗っ取りの候補です。
5. 対象組織が文書化したスコープには含まれていないものの、到達可能で旧バージョンのソフトウェアが稼働している staging-api.target.com と dev-portal.target.com を発見します。
6. 対象組織が把握している資産インベントリと、CTログから特定した攻撃対象領域のギャップを示し、調査結果を報告します。

注意点：

• CTログで発見されたすべてのサブドメインがスコープ内だと決めつけ、資産の所有者に確認しない
• ワイルドカードDNS応答を確認せず、存在しないサブドメインがすべての名前を受け付けるDNS応答により存在するように見える可能性を見逃す
• 包括的に網羅するためのパッシブDNSデータベースとの照合を行わず、CTデータだけに依存する

出力形式

## CT Log Monitoring Report

**Domain**: example.com
**Monitoring Period**: 2026-03-01 to 2026-03-19
**Total Certificates Tracked**: 142
**New Certificates Detected**: 7
**Alerts Generated**: 2

### Alert: Unauthorized CA Issuance
- **Severity**: Critical
- **Certificate CN**: secure-login.example.com
- **SANs**: secure-login.example.com, www.secure-login.example.com
- **Issuer**: Unknown Free CA (NOT in authorized CA list)
- **Serial**: 04:A3:B7:2F:...:9E
- **Not Before**: 2026-03-18T00:00:00Z
- **Not After**: 2026-06-16T00:00:00Z
- **CT Log**: Google Argon 2026
- **SCT Timestamp**: 2026-03-17T22:15:33Z
- **Action Required**: Investigate immediately, request revocation

### Subdomain Discovery Summary
- **Total Unique Subdomains**: 89
- **New Subdomains This Period**: 3
  - api-v3.example.com (DigiCert, valid)
  - staging-new.example.com (Let's Encrypt, valid)
  - old-portal.example.com (expired 2025-12-01, CNAME to Azure -- takeover risk)

### Typosquatting Alerts
| Domain | Certificate Count | Issuer | Action Required |
|--------|-------------------|--------|-----------------|
| exarnple.com | 2 | Let's Encrypt | Investigate phishing |
| examp1e.com | 1 | ZeroSSL | Investigate phishing |