これまで、インターネットの信頼は「信頼の連鎖（Chain of Trust）」によって守られていると解説してきました。しかし、もし「信頼されているはずの認証局（CA）」が、悪意ある者にハッキングされたり、手違いで偽の証明書を発行してしまったらどうなるでしょうか？
実際、過去には大手認証局が偽のGoogle証明書を発行してしまうなどの事件が起き、PKI（公開鍵基盤）の根幹を揺るがす事態となりました。この弱点を克服するためにGoogleが提唱し、現在のWeb標準となった仕組みがCT（Certificate Transparency：証明書の透明性）です。
CTが登場した背景：認証局は「絶対」ではない
従来の「PKI（公開鍵基盤）」では、ブラウザが信頼している認証局が「正しい」と言えば、それがたとえ誤発行された偽の証明書であっても、ブラウザは警告を出すことができませんでした。
- 過去の事件（DigiNotar事件など）： 認証局が攻撃を受け、偽の証明書が大量に発行されました。これにより、特定の政府が市民の通信を傍受するといった深刻な被害が発生しました。
- 課題： 証明書が発行された事実を、ドメインの所有者や第三者が知る手段がなかったため、発見が大幅に遅れました。
CTは、この「不透明な発行プロセス」をオープンにし、「誰が・いつ・どのドメインの証明書を発行したか」を誰もが監視できるようにする仕組みです。
CTを構成する3つの要素
CTは、主に以下の3つの役割によって運用されています。
① CTログ（Log Server）
発行されたすべての証明書を記録する「公開帳簿」です。一度記録されたデータは削除も改ざんもできない「追記のみ（Append-only）」の特性を持ちます。
- 役割： 世界中に複数のログサーバーが存在し、24時間体制で発行記録を蓄積し続けます。
② モニター（Monitor）
ログサーバーを常に監視するプログラムです。
- 役割： ドメイン所有者などはモニターを利用し、「自分の知らないところで、自分のドメインの証明書が勝手に発行されていないか」をチェックします。もし不審な発行があれば、即座に「証明書の失効（CRL/OCSP）」の手続きを取ることができます。
③ オーディター（Auditor）
ログサーバーが正しく動作しているか、不正な書き換えが行われていないかを検証する役割です。
SCT（Signed Certificate Timestamp）の仕組み
CTが実際にどのように機能しているのかを理解する上で欠かせないのが、SCTというデータです。
認証局が証明書を発行する際、まずログサーバーに「これからこの証明書を発行します」という予約情報を送ります。ログサーバーはそれを受け取ると、「確かに記録を受け付けた」という受領証であるSCTを返します。
認証局は、このSCTを証明書の中に埋め込んでから発行します。
ブラウザによる検証
私たちがWebサイトにアクセスした際、ブラウザは以下の点を確認します。
- 証明書そのものが正当か（信頼の連鎖の検証）。
- 証明書の中に有効なSCTが含まれているか。
もしSCTが含まれていない、あるいは無効な場合、現在のGoogle Chromeなどの主要ブラウザは「このサイトはCTポリシーに違反しています」として、安全な接続を拒否します。これにより、ログに記録せずに「こっそり偽の証明書を発行する」ことが不可能になりました。
CTがもたらしたセキュリティの進化
CTの導入によって、Webセキュリティは「事後対策」から「早期発見」へと大きく進化しました。
- 不正発行の抑止： ログが公開されているため、認証局は不適切な発行に対して極めて慎重になります。
- ドメイン所有者による自衛： 自分のドメインに対する「全発行履歴」を把握できるため、フィッシング詐欺などの予兆をいち早く察知できます。
- 認証局の信頼性向上： 透明性が確保されることで、善良な認証局の信頼がより強固なものとなりました。
まとめ：透明性が支えるデジタルの信頼
CTは、「デジタル証明書」という信頼の証を、第三者の目によってさらに厳格に監視する「監査」の仕組みです。
- CTは、証明書の発行履歴をすべて公開する仕組み。
- SCTは、ログに記録されたことを証明する「受領証」。
- モニターによる監視で、不正発行をリアルタイムに近い速度で発見できる。
- PKIの弱点を補完し、現代の常時SSL化社会を支える不可欠な技術。
私たちが毎日何気なく目にしている「鍵マーク」の裏側では、このCTという仕組みが休むことなく世界中の証明書を監視し続けているのです。
コメント