証明書の透明性(CT)とはどのような仕組みなのですか？
CT (Certificate Transparency: 証明書の透明性）は、既存の認証局インフラストラクチャの中において、エンティティによって承認された SSL/TLS サーバ証明書の発行後の検証方法として機能します。
証明書発行のプロセスを以下に示します。CT によって導入された新しいステップは青色で示します。
- サーバオペレータが認証局から証明書を購入する。
- 認証局がサーバオペレータを検証する。
- 認証局がプレ証明書を作成する。
- 認証局がログサーバーにプレ証明書を登録する。ログサーバーは SCT （Signed Certificate Timestamp）を返す。
- 認証局が SSL/TLS サーバ証明書を発行する。
- SSL/TLS サーバ証明書には、SCT （Signed Certificate Timestamp）が含まれる場合がある。
- TLS ハンドシェイク中にブラウザが SSL/TLS サーバ証明書を検証する。
- ブラウザは、TLS ハンドシェイク中に提供された SCT を、OCSP ステープリング、TLS 拡張、または証明書埋め込み情報のいずれかによって検証する。
- ブラウザがサーバーに接続する。
- SSL/TLS サーバ証明書により、ブラウザからサーバーに渡されるすべてのデータが暗号化される。
TLS ハンドシェイク中に SCT を配信する方法は 2 つあります（詳しくはこちら）。SCT の提供方法の 1 つを示すプロセスの図を以下に示します。
証明書の透明性(CT)の構成要素
CT システムは CA、証明書ログ、証明書監視役、および証明書監査役の 4 つの要素で構成されています。これらの構成要素のよくある構成を次の図に示します。それぞれの構成要素について、以下で詳しく説明します。
認証局
CT は、パブリックに信頼されている既存の認証局システム内で動作します。CT を使用すると、認証局はパブリックなログに証明書発行の証跡（SCT）を含めることができ、ブラウザはハンドシェイク中にこれらの SCT を確認できるようになります。証明書のログは認証局が適切に運用されていることを示す証拠であり、ログを通して認証局の運用状況を把握できます。
証明書ログ
発行されるすべての SSL/TLS サーバ証明書の記録が証明書ログに保持されるのが理想ですが、初期ロールアウト時点では EV 証明書に限定されています。複数の独立したログが必要な理由はいくつかあります。1) 複数のログが存在すれば、ログ障害時のバックアップとして使用できます。2) ログが独立していれば、1 つのログまたはログオペレータが危殆化した場合でも証明書の検証が可能です。3) ログが独立していれば、単一の政府の措置によってすべてのログから発行の証拠を削除することは不可能になります。4) 複数の独立したログがあれば、認証局とログオペレータが共謀して誤発行を隠蔽することができなくなります。
すべてのログは次のような特性を備えています。
- 追加書き込みのみ - 証明書はログに追加することのみ可能で、削除、修正したり、過去にさかのぼって挿入したりすることはできません。
- 暗号化による保証 - ログには改ざんを防ぐためにマークルハッシュ木と呼ばれる暗号化メカニズムが採用されています。
- 公に監査可能 - 誰でもログを照会して、誤発行された証明書や不正な証明書を探すことができます。すべての証明書ログは、その URL と公開鍵を公表する必要があります。
証明書監視役
証明書監視役（モニター）とは、大規模ブランド所有者や認証局など、証明書のログに不審な動きがないか監視するすべての人を指します。
監視役は、HTTP GET コマンドを使用してログから情報を取得できます。ログ監視サービスはお客様自身が行うことも、他社に委託して行うこともできます。デジサートでは、お客様向けにログ監視サービスを提供する予定です。
証明書監査役
証明書監査役はログをチェックし、ログが他のログと一致しているか、新しい項目が追加されているか、誰かが証明書を過去にさかのぼって挿入、削除、または修正したことによってログが破損していないかを確認します。
今後、監査はブラウザ側に組み込まれて自動的に処理されるようになる可能性があります。ただし、監査役は独立したサービスである場合もあれば、監視役の二次的な機能となる場合もあります。
