Certificate Transparency を使う方法

问题

認証局（CA）はドメイン所有者に知られることなく証明書を誤発行し、中間者攻撃を可能にしてしまうことがあります。Certificate Transparency（RFC 6962）を使って不正な証明書を検出し、誤発行を監視する必要があります。

前提条件

• X.509 証明書と CA 階層の理解
• Merkle ツリーとインクルージョン証明への習熟
• TLS 証明書の検証に関する知識

ステップ

1. 1. Understand the CT log architecture

   Certificate Transparency logs are append-only Merkle trees of certificates. When a CA issues a certificate, it must submit it to one or more CT logs. The log returns a Signed Certificate Timestamp (SCT) — a promise that the certificate will be included in the log. Browsers require SCTs in TLS handshakes; without them, certificates are rejected. The append-only nature means once logged, a certificate cannot be hidden or removed.

   入力

   certificate issued by CA

   输出

   SCT: { log_id, timestamp, extensions, signature }

2. 2. Verify SCTs embedded in certificates

   When receiving a TLS certificate, check for embedded SCTs (in the certificate's X.509 extensions, OID 1.3.6.1.4.1.11129.2.4.2). For each SCT: verify the log's signature on the SCT, check the timestamp is within the certificate's validity period, and verify the log is trusted (in the CT log list). Use the hash tool to compute Merkle tree hashes for inclusion proofs. At least 2 SCTs from different logs are typically required.

   入力

   certificate with 3 embedded SCTs

   输出

   verified: 3/3 SCTs valid | logs: Google Argon, Cloudflare Nimbus, Let's Encrypt Oak

3. 3. Monitor CT logs for your domains

   Set up monitoring of CT logs for certificates issued for your domains. Use APIs like Google's CT search (https://transparencyreport.google.com) or crt.sh to query for certificates matching your domain. Alert on any certificate you did not request. Check periodically: query for your domain, compare against your known certificate inventory, investigate any unknown certificates immediately. Use the DNS tools to verify the domain ownership.

   入力

   domain: example.com

   输出

   found: 2 certificates | expected: 2 | status: OK

4. 4. Respond to misissued certificates

   If you detect an unauthorized certificate: (1) immediately report to the issuing CA for revocation, (2) revoke the certificate via OCSP or CRL, (3) investigate how the misissuance occurred (domain validation bypass, CA compromise), (4) consider using CAA (Certification Authority Authorization) DNS records to restrict which CAs can issue for your domain, (5) use DANE/TLSA records as an additional verification layer. Document the incident and update monitoring.

   入力

   unauthorized cert for example.com

   输出

   action: revoke + report CA + add CAA record

期待される結果

ドメインに対する不正な証明書発行を検出する、Certificate Transparency ログの継続監視。すべての正当な証明書には検証済みの SCT が付与されます。

よくあるエラー

Not checking SCTs during TLS validation

Modern browsers enforce CT, but custom TLS clients may not. Verify SCT presence and validity in your TLS stack, not just certificate chain validation.

Monitoring only one CT log

Monitor multiple logs (Google, Cloudflare, Let's Encrypt) since certificates may appear in any of them. Use aggregate APIs that search across all logs.

Ignoring CAA DNS records

CAA records restrict which CAs can issue certificates for your domain. Set them to prevent unauthorized CAs from issuing, reducing misissuance risk at the source.

トラブルシューティング指引

• If your certificate is rejected for lack of SCTs, ensure your CA supports CT and submits to logs during issuance. Let's Encrypt and most modern CAs do this automatically.
• For internal PKIs (not publicly trusted), CT does not apply — use private CA monitoring instead.
• If monitoring produces too many false positives, filter by certificate validity period and issuer to reduce noise.

セキュリティ上の制限

• CT detects misissuance but does not prevent it — the certificate is still valid until revoked. Response speed matters.
• CT logs are public — your domain names and subdomains are visible in the logs. Do not use CT for internal/private domain names.
• All certificate verification happens locally; no certificate data is sent to third parties.