証明書の透明性とは - HTTPS の信頼を支える公開監査の仕組み
HTTPS で通信が暗号化されていても、接続先のサーバーが提示する TLS 証明書が不正に発行されたものであれば、暗号化は無意味です。攻撃者が認証局 (CA) を侵害して偽の証明書を取得すれば、正規のドメインになりすまして通信を傍受できます。
Certificate Transparency (CT、証明書の透明性) は、この問題に対する Google 発の解決策です。すべての TLS 証明書の発行を公開ログに記録し、誰でも監査できるようにすることで、不正な証明書の発行を迅速に検知する仕組みです。2018 年 4 月以降、Chrome は CT ログに登録されていない証明書を信頼しなくなりました。
なぜ証明書の透明性が必要になったのか
CT が生まれた背景には、認証局の信頼モデルが抱える構造的な問題があります。
認証局の信頼モデルの脆弱性
ブラウザは数百の認証局を「信頼されたルート CA」として登録しています。これらの CA はいずれも、任意のドメインに対して証明書を発行する権限を持っています。つまり、1 つの CA が侵害されるだけで、インターネット全体の HTTPS の信頼が崩壊する可能性があります。
実際に起きた不正発行事件
- DigiNotar 事件 (2011 年): オランダの認証局 DigiNotar が侵害され、google.com を含む 500 以上のドメインに対して不正な証明書が発行された。イラン政府による Gmail ユーザーの通信傍受に使用されたとされる。DigiNotar はこの事件で信頼を失い、破産に至った
- Symantec の不正発行 (2015-2017 年): Symantec 傘下の CA が、ドメイン所有者の承認なしに多数のテスト証明書を発行していたことが発覚。Google は段階的に Symantec の証明書の信頼を取り消した
- CNNIC 事件 (2015 年): 中国の CNNIC が中間 CA 証明書を不適切に委譲し、その中間 CA が Google ドメインの不正な証明書を発行した
これらの事件は、認証局を「信頼する」だけでは不十分であり、発行された証明書を継続的に監視する仕組みが必要であることを示しました。
CT の技術的な仕組み
CT は 3 つのコンポーネントで構成されています。
1. CT ログサーバー
CT ログは、発行されたすべての証明書を時系列で記録する追記専用 (append-only) のデータ構造です。Merkle ハッシュツリーを使用しており、一度記録されたエントリを改ざんすることは計算量的に不可能です。
認証局は証明書を発行する際、少なくとも 2 つの独立した CT ログサーバーに証明書を提出します。ログサーバーは証明書を記録し、SCT (Signed Certificate Timestamp) と呼ばれる署名付きタイムスタンプを返します。この SCT が「この証明書は CT ログに記録されている」ことの証明になります。
2. モニター
モニターは CT ログを定期的にスキャンし、不審な証明書の発行を検知するシステムです。ドメイン所有者は、自分のドメインに対して発行された証明書をモニターで監視できます。
例えば、あなたが example.com のドメイン所有者であれば、CT ログを監視することで、自分が依頼していない example.com の証明書が発行された場合に即座に検知できます。
3. 監査者 (Auditor)
監査者は、CT ログサーバーが正しく動作しているかを検証します。ログの一貫性 (過去のエントリが改ざんされていないか) と、SCT に対応するエントリが実際にログに存在するかを暗号学的に検証します。ブラウザが監査者の役割を兼ねることもあります。
ブラウザによる CT の強制
CT の実効性は、ブラウザが CT ログへの登録を強制することで担保されています。
- Chrome: 2018 年 4 月 30 日以降に発行された証明書は、CT ログに登録されていなければ信頼しない。証明書の有効期間に応じて、2〜3 個の SCT が必要
- Safari: Apple も独自の CT ポリシーを策定し、Safari で CT を強制している
- Firefox: CT の強制は段階的に導入中
CT ログに登録されていない証明書でサイトにアクセスすると、ブラウザは「この接続ではプライバシーが保護されません」といった警告を表示し、接続をブロックします。
CT ログの活用 - ドメイン所有者ができること
CT ログは公開されており、誰でも検索できます。ドメイン所有者は以下のツールを使って、自分のドメインに対する証明書の発行状況を監視できます。
- crt.sh: Sectigo が運営する CT ログ検索エンジン。ドメイン名で検索すると、そのドメインに発行されたすべての証明書を一覧できる
- Google Certificate Transparency Search: Google が提供する CT ログの検索ツール
- Certspotter: SSLMate が提供する CT モニタリングサービス。新しい証明書が発行されるとメールで通知する
定期的に自分のドメインの証明書発行状況を確認し、身に覚えのない証明書が発行されていないかをチェックすることを推奨します。不正な証明書を発見した場合は、発行元の CA に失効 (revocation) を依頼してください。
CT とプライバシーのトレードオフ
CT ログは公開情報であるため、プライバシーに関する懸念もあります。
- 証明書に含まれるドメイン名 (サブドメインを含む) が公開される。内部システムのサブドメイン (例: staging.internal.example.com) が外部に露出する可能性がある
- 攻撃者が CT ログを監視し、新しいサブドメインの存在を発見して攻撃対象にする可能性がある
- ワイルドカード証明書 (*.example.com) を使用することで、個別のサブドメイン名の露出を防げる
このトレードオフは、CT の透明性がもたらすセキュリティ上の利益と、サブドメイン名の露出リスクを天秤にかけて判断する必要があります。多くの場合、不正証明書の検知能力の方が、サブドメイン名の秘匿よりも重要です。
CAA レコードとの併用
CT と併せて、DNS の CAA (Certification Authority Authorization) レコードを設定することで、証明書の不正発行リスクをさらに低減できます。
CAA レコードは、そのドメインに対して証明書を発行できる CA を DNS レベルで制限する仕組みです。例えば、Let's Encrypt のみに発行を許可する場合は以下のように設定します。
example.com. IN CAA 0 issue "letsencrypt.org"
CAA レコードが設定されていれば、指定された CA 以外は証明書を発行できません (RFC 8659 により、CA は発行前に CAA レコードを確認する義務がある)。CT ログによる事後的な検知と、CAA レコードによる事前の制限を組み合わせることで、多層的な防御が実現します。
まとめ
Certificate Transparency は、HTTPS の信頼基盤を支える重要なインフラです。認証局の不正や侵害を前提とした設計であり、すべての証明書発行を公開ログに記録することで、不正な証明書の発行を迅速に検知できます。
ドメイン所有者は、crt.sh などのツールで自分のドメインの証明書発行状況を定期的に監視し、CAA レコードを設定して発行可能な CA を制限することを推奨します。証明書の不正発行はフィッシングメールの信頼性を高める手段にもなるため、メールセキュリティの対策と合わせて防御を固めることが重要です。IP 確認さんで自分の接続が HTTPS で保護されていることを確認し、セキュリティヘッダーの設定と合わせて、Web 通信の安全性を総合的に高めてください。
PKI と証明書の仕組みを体系的に理解するには、暗号技術の解説書が参考になります。