証明書透明性とは

この記事は約 2 分で読めます

証明書透明性 (Certificate Transparency, CT) とは、SSL/TLS 証明書の 発行をすべて公開ログに記録し、誰でも監査できるようにする仕組みです。認証局 (CA) が 不正な証明書を発行した場合に、ドメイン所有者やブラウザベンダーが 速やかに検知できることを目的としています。Google のエンジニア Ben Laurie と Adam Langley が 2013 年に RFC 6962 として提案し、現在では Chrome をはじめとする主要ブラウザが CT への対応を必須としています。

DigiNotar 事件と CT 誕生の背景

CT が生まれた直接のきっかけは、2011 年のオランダの認証局 DigiNotar の 侵害事件です。攻撃者が DigiNotar のシステムに侵入し、google.com を 含む 500 件以上の不正な証明書を発行しました。これらの証明書はイランの ユーザーに対する中間者攻撃に使用され、Gmail の通信が傍受されたと されています。

この事件は、PKI (公開鍵基盤) の 根本的な弱点を露呈しました。どの認証局でも任意のドメインの証明書を 発行でき、ドメイン所有者がそれを知る手段がなかったのです。DigiNotar は 信頼を失い廃業に追い込まれましたが、同様の事件の再発を防ぐ技術的な 仕組みとして CT が設計されました。

CT ログの仕組み - Merkle ツリー

CT ログは、暗号学的なデータ構造である Merkle ツリー (ハッシュツリー) で 管理されます。新しい証明書がログに追加されるたびにツリーが更新され、 過去のエントリを改ざんするとハッシュ値の 不整合が発生して即座に検出できます。

CT ログは複数の独立した組織 (Google、Cloudflare、DigiCert など) が 運営しており、認証局は証明書を発行する際に少なくとも 2 つ以上のログに 登録する必要があります。ログの運営者が結託しない限り、不正な証明書の 隠蔽は極めて困難です。

SCT (Signed Certificate Timestamp) の検証

認証局が証明書を CT ログに登録すると、ログサーバーから SCT (Signed Certificate Timestamp) が返されます。SCT は「この証明書がログに記録 された」ことの暗号学的な証明であり、ブラウザは TLS ハンドシェイク時に SCT を検証します。

SCT の配信方法は 3 つあります。証明書自体に SCT を埋め込む方法 (X.509 v3 拡張)、TLS ハンドシェイクの拡張で送信する方法、OCSP Stapling で送信する方法です。Let's Encrypt をはじめとする主要な 認証局は、証明書への埋め込み方式を採用しています。

Chrome の CT 必須化 (2018 年)

Google Chrome は 2018 年 4 月 (Chrome 68) 以降、すべての新規発行 証明書に CT 対応を必須としました。SCT が付与されていない証明書で HTTPS 接続すると、Chrome はセキュリティ警告を表示します。この決定は CT の普及を決定的に加速させ、現在では事実上すべての公開認証局が CT ログへの登録を標準プロセスに組み込んでいます。デジタル証明書の 信頼性を支える基盤として、CT は不可欠な存在になりました。

不正証明書の検知と実務での活用

CT ログは crt.sh や Google の Certificate Transparency Search で 誰でも検索できます。ドメイン管理者は自社ドメインの証明書発行を モニタリングすることで、不正な証明書の発行を早期に検知できます。 実際に、2017 年に Symantec 傘下の認証局が Google のドメインに対して 不正なテスト証明書を発行した事実が CT ログから発覚し、最終的に Symantec の認証局事業が DigiCert に売却される事態に至りました。

CT ログの監視は、公開鍵暗号に 基づく PKI の信頼モデルを補完する重要な仕組みです。暗号化の基礎やフィッシング対策、ブラウザのパスワード安全性の 記事もあわせて参照してください。

暗号技術の関連書籍は Amazonでも探せます。