60日ごとに届く警告は誰も読まない 証明書監視のノイズ問題

3行まとめ

• 証明書の透明性ログを見張る仕組みが、65万を超えるドメインで動いています
• 証明書は自動で更新されるため、そのたびに通知が飛んでいました
• 証明書の有効期間は2029年までに最長47日へ縮まる予定です

何が起きたか

Cloudflare が証明書の透明性ログの監視機能を正式提供に切り替えました。2019年にパブリックベータとして始まり、いまは65万を超える顧客ドメインで有効になっています。公開のログに自社ドメイン向けの新しい TLS 証明書が現れると、メールで知らせる機能です。

変わったのは通知の量です。Cloudflare が代理で発行した証明書も同じログに載るため、これまでは通常の自動更新まで通知されていました。今回から、自社が発行したと確認できた分は送信前に取り除かれます。

利用者の手元に届くのは、Cloudflare が発行していない証明書の通知だけになりました。

なぜ難しい・何がすごいか

証明書は「このドメインの持ち主は本物だ」と第三者が保証する仕組みです。保証する側を認証局と呼びます。認証局がだまされたり手違いを起こしたりすると、他人のドメインの証明書が世に出てしまいます。

それを外から見つけるための公開台帳が CT ログです。発行された証明書をすべて記録に書き出し、誰でも検索できる状態にします。Chrome や Safari は、ログに載っていない証明書を信用しません。

だから発行は必ず記録に残ります。裏返せば、正常な更新もすべて残ります。

Universal SSL の証明書は最短60日ごと、年6回ほど自動で更新されます。その1回ごとに通知が飛んでいました。

コミュニティフォーラムでは、全サイトで機能を切ったという利用者がこう述べています。

最後のほうは読んでもいませんでした

たとえ話

火災報知器を思い浮かべてください。料理の湯気で毎日鳴る報知器は、そのうち誰も見に行かなくなります。

本物の火事でも音は同じです。鳴っているのに、情報としては届きません。証明書の通知も同じ場所に落ちていました。

用語ミニ辞典

• TLS証明書: そのサイトが名乗るドメインの持ち主であることを示す電子的な証明書。
• CTログ（証明書の透明性ログ）: 発行された証明書を書き出す公開の記録。誰でも中身を調べられる。
• 認証局（CA）: 証明書を発行する事業者。ブラウザはこの署名を信頼の起点にする。
• CA/Browser Forum: ブラウザ側と認証局が証明書の規則を決める場。有効期間の上限もここで決まる。
• SPKI: 証明書に入る公開鍵の情報のまとまり。SubjectPublicKeyInfo の略。

技術者向けの深掘り

難所は、2つのシステムをつなぐ照合キーの選び方でした。証明書の発注側と、ログを読んで通知する側は別々の系として作られています。通知側が持っているのはログから読めた情報だけです。

ログには証明書1件につき2つのエントリが載ります。pre-certificate と final certificate です。通知側はこの対を stripped_fingerprint で重複排除していました。

DER エンコードした TBSCertificate のハッシュです。通知側の内部にしかない値でした。

これを発注側に持たせる案は成立しません。発注側は pre-certificate を受け取らないため、照合したい瞬間にはまだ計算できないからです。

採用されたのは公開鍵でした。公開鍵は SPKISPKI証明書に入る公開鍵の情報のまとまり。SubjectPublicKeyInfo の略。 という構造に入り、鍵生成から CSR、pre-cert、final cert まで同じ値で流れます。

発注側は CSR から spki_sha256 を計算し、発行が始まる前に記録します。通知側はログエントリから同じ値を計算して照合し、記録があれば通知を止めます。

発行のたびに新しい鍵ペアを作るため、値は実質的に一意です。利用者が自分でアップロードした証明書は記録がなく、これまでどおり通知されます。

これは自分に関係ある？

• サイトを持っている人: 自分のドメインに身に覚えのない証明書が出ていないか、公開のログから外側で確認できる仕組みがあります。
• 運用担当: 有効期間が47日に縮めば、更新の回数はいまより増えます。通知はノイズが増える前提で組み直す話になります。
• 監視を作る人: 自分たちが起こしたイベントをどう除外するか、どのキーなら両方の系で同じ値になるか。今回の設計はその一般解に近い形です。