CloudflareのCTモニタリングがGAに、SPKIフィルタでノイズを排除
CloudflareのCertificate Transparencyモニタリングが一般提供開始。重要な修正として、SPKIハッシュを使いCloudflare発行の証明書をフィルタリングし、アラート疲れを解消します。

Cloudflareは、Certificate Transparency(CT)モニタリングサービスが一般提供(GA)になったと発表しました。目玉の変更は、長らく待たれていたアラート疲れへの修正です。このサービスは、ドメインの新しいTLS証明書が公開CTログに出現するたびにメールで通知するものですが、その大半がCloudflare自身の自動証明書発行によるノイズで埋もれていました。
問題は根本的なものでした:Universal SSLの更新、Advanced Certificate Manager、バックアップ証明書はすべて、設計上公開CTログに記録されます(ログに記録されていない証明書はChromeやSafariから信頼されません)。証明書の更新が最短60日ごとに行われ、CA/Browser Forumが2029年までに証明書の最大有効期間を47日に短縮しようとしている中、日常的な更新の量は爆発的に増えていました。顧客は通知を無視するようになり、コミュニティフォーラムのあるユーザーは「完全に正常な証明書更新のスパムを定期的に受信するのにうんざりした」として、機能を完全に無効化したと述べています。
技術的な修正:共有識別子としてのSPKI
核心的な課題は、証明書発注サービスとCTアラートサービスの2つの独立したシステムが同じ証明書を扱いながら、適切なタイミングで共通の識別子を共有していなかったことです。アラートサービスはログエントリのみを参照し、発注サービスは発行データを持っているものの、それを関連付ける手段がありませんでした。
明白な候補であるstripped_fingerprintは、プリ証明書から導出されるため失敗しました。発注サービスはプリ証明書を参照しないからです。最終証明書が届く頃には、アラートサービスはすでにプリ証明書のログエントリを処理し、アラートを発火している可能性があります。
解決策:公開鍵、具体的にはDERエンコードされたSubjectPublicKeyInfo(SPKI)のSHA-256ハッシュであるspki_sha256を使用します。この識別子はすべての条件を満たします:
- 早期:鍵生成時に記録され、ログに何かが記録される前から存在。
- 一貫性:CSR、プリ証明書、最終証明書で同一。
- 再現可能:アラートサービスはログエントリだけから再計算可能。
- 一意性:Cloudflareは発行ごとに新しい鍵ペアを生成するため、衝突は天文学的に起こりにくい。
現在、アラートサービスはログエントリを確認するとspki_sha256を再計算し、発注サービスのデータベースを照合します。一致すれば証明書はCloudflare管理であり、アラートは抑制されます。一致しなければ外部発行であり、従来どおりアラートが発火します。
実際の意味
フィルタリングはUniversal SSL、Advanced Certificate Manager、Total TLS、バックアップ証明書を対象とします。また、ログに記録されたものの完了しなかった放棄されたプリ証明書も沈黙させます。これらは以前は説明のつかない証明書のように見えていました。アップロードしたカスタム証明書は引き続きアラートをトリガーします。Cloudflareはその鍵を生成していないためです。
メールアラート自体も改善されました:件名に対象ホスト名が含まれ、本文にはCloudflareダッシュボードの証明書へのリンクが含まれ、迅速な確認が可能です。
今後の予定
CloudflareはCTモニタリングをNotificationsシステムと統合し、チームがアラートをwebhook、PagerDuty、追加のメール宛先にルーティングできるようにする計画です。この機能はすべてのプランで追加費用なしで利用でき、既存ユーザーは何もする必要がありません。フィルタリングはすでに有効です。
受信トレイに届くアラートは、注目に値するものだけ:Cloudflareが発行していない、予期しない証明書。
ディスカッション
0 件のコメント
最初のコメントを投稿しましょう。