CTはCertificate Pinningと同様Googleによって考案され、2013年にRFC6962としてRFC化されました。
基本的な考え方はCertificate Pinningと同じ「ホワイトリスティング」です。正規に発行された証明書の情報を「Log」として登録し、TLSクライアントがサーバに接続する際にこの「Log」を参照することで証明書の正当性を検証できるようにしようというものです。

CTの特徴として、以下のようなポイントがあります。

・Logへの証明書登録をOpenにし、誰でも証明書発行あるいは取得後すぐに登録が可能なようにしている
・マークル木(Merkle tree)を使い、誰でもLogの完全性を簡単に検証できるようにしている
・認証局が、自局から意図せず発行された証明書がLogに登録されていないかモニターすることができる

なお、CTの立場はあくまでも証明書の信頼性を担保するための付加的な技術であり、証明書のパス検証やステータス確認については従来の技術に依存するということになっています。

実はChromeにはすでにサーバ証明書がCTに準拠している（＝Logに登録されている）かどうかを表示する機能が実装されています。 CTのLogに登録されていない証明書の情報を表示すると、右図のように「公開監査記録がありません」と表示されます。 Logに登録されている証明書であれば、登録されている情報を見ることができます。

CTの公式ページでは、その目的は以下の3つであるとしています。

　・ドメイン所有者の証明が明確にされない状態で、CAがそのドメインに対して証明書を発行してしまうことを不可能（あるいは限りなく困難）にする

　・あらゆるドメイン所有者やCAが証明書の誤発行や不正発行を検知するためのオープンな監査とモニタリングのシステムを提供する

　・（可能な限り多くの）ユーザを、誤発行や不正発行された証明書による詐欺から守る

不正発行や誤発行された証明書の検知を正確に素早く行うことを可能とすることで、その証明書による被害を最小限にすることを目指しているのです。


CTを構成するコンポーネントは以下の３つです。

Log	Ceritificate logは、「暗号的に担保され、誰でも監査可能で、追記のみが可能な証明書のレコードを維持管理するためのシンプルなネットワークサービス」です。ログはハッシュ木（Merkle tree）を使って、その完全性を誰もが検証できるようになっています。
Monitors	Monitor(モニター)とは、「定期的にすべてのログサーバにコンタクトし、不審な証明書がないかどうかを監視する公的に運用されたサーバ」です。 例えば、認証局がMonitorとして定期的に、ログサーバに格納されている自認証局が発行したとされている証明書の情報にアクセスすることによって、意図しない証明書（＝その認証局から不正に発行された証明書）の情報が格納されていないかどうかを確認することができます。
Auditors	Auditorとは、「主に2つの機能を持つ軽量なソフトウェアコンポーネントである」とされています。2つの機能とは、「Logが正しく動作しており、暗号的に整合性が担保されていることを検証する」機能と、「特定の証明書がLogに記録されているかどうかを検証する」機能です。 RFC6962では、AuditorはTLSクライアントに統合されるであろうと書かれています。 ブラウザがTLSのクライアントとして動作する際、Auditorを使ってサーバ側の証明書が正常にLogに格納されているかを検証することによって、いわゆる「怪しい証明書」が使われているサイトかどうかを確認することができます。

Logには誰でも証明書の情報をPOSTできることになっていますが、主に想定されているのは認証局とWebサーバの管理者からのPOSTです。
Logに証明書をPOSTすると、Logからはsigned certificate timestamp(SCT)と呼ばれるデータが返されます。SCTは、maximum merge delay (MMD)と呼ばれる時間内にLogにPOSTされた証明書データが格納されることを保証するデータです。証明書の信頼者(Relying Party)であるブラウザなどのTLSクライアントは、サーバ側の証明書と一緒にデリバリされるSCTを使って、Logの中にその証明書のデータが登録されているかどうかを確認することができます。

上記で述べたように、TLSクライアントはSCTを入手することで、その証明書がLogに登録されているかを検査することができるようになります。
TLSクライアントへのSCTのデリバリの方法としては、以下の3種類が想定されています。

(1) 証明書の拡張領域(Extantion)にSCTを格納する

認証局が証明書を発行する際に証明書をLogに登録し、Logから返されたSCTを証明書の拡張領域に格納して証明書を発行します。
お気づきの方もいらっしゃるかもしれませんが、上記を言葉通りに受け止めると、証明書を発行する前に証明書をLogに登録しなければならなくなってしまいます。
このため、RFC6962では本物の証明書（便宜上「本番証明書」と呼びます）を発行する前に「事前証明書(precertificate)」を発行しそれをLogに登録しろと定義されています。
事前証明書とは、本番証明書と同じシリアル番号、サブジェクトDN、有効期間を持ち、同じ署名アルゴリズムで署名された証明書です。厳密には異なりますが、本番証明書からSCTが除かれたもの、と考えるとわかりやすいかもしれません。
RFCでは事前証明書は「本番証明書を発行する認証局が発行した証明書を持つ認証局（つまり本番証明書を発行するCAのサブCA）」あるいは「本番証明書を発行する認証局」から発行されなければならないとしています。 このことがちょっとした議論を呼んでいるのですが、それについては下記の囲みの中で触れたいと思います。

TLSクライアントは、サーバから証明書を受け取ると、通常の検証手順に加えてAuditorを使ってその証明書がLogに格納されているかどうか確認します。SCTは証明書の中に格納されていますので、そのほかに特別な情報は必要ありません。

(2) TLSのエクステンションにSCTを格納する

もう一つの選択肢は、TLSのサーバ側でハンドシェイク時にTLSのエクステンションとしてSCTを格納してクライアントのデリバリする方法です。
この方法をとる場合、Logへの格納をリクエストするのは認証局ではなく、Webサーバの管理者です。 証明書が発行されて手元に届いたら、Webサーバ管理者はLogへ証明書情報の格納をリクエストします。Logから返されたSCTを保管し、signed_certificate_timestampという拡張としてTLSハンドシェイクの際にクライアントに渡します。クライアントはハンドシェイクで渡された証明書とSCTからAuditorを使ってその証明書がLogに格納されているかどうか確認します。

(3) OCSPステイプリングを利用する

最後の選択肢は、OCSPステイプリングを使う方法です。
OCSPステイプリングというのは、OCSPの拡張の一つです。
通常TLSクライアントがWebサーバの証明書のステータスをOCSPによって確認する場合、TLSクライアントが自らOCSPサーバ（レスポンダ）に問い合わせを行います。OCSPステイプリングでは、TLSクライアントの代わりにWebサーバが自らの証明書のステータスをOCSPレスポンダに問い合わせ、その結果（OCSPレスポンス）をレスポンスの有効期間中保持します。クライアントから接続される際、TLSハンドシェイクのやり取りの中にこのOCSPレスポンスを「ホチキス止め(Stapling)」するようにしてクライアントに送ることによって、クライアントは自らがOCSPレスポンダに問い合わせることなく、Webサーバ証明書の有効性を確認することができます。

前置きが長くなってしまいましたが（機会があればOCSPステイプリングを含む失効情報のハンドリング方法についても改めて書いてみたいと思います。）、このホチキス止めされるOCSPレスポンスの中にSCTを格納してデリバリしようというのが最後の選択肢です。
認証局は証明書を発行すると同時に、その証明書情報の格納をLogにリクエストしてSCTを取得します。(1)の場合と違い、証明書にはSCTを格納しないので、Logへの格納要求は証明書発行後でよく、取得したSCTは証明書と紐づけられる形で認証局が保持しておきます。
Webサーバから、そのサーバの証明書のステータスについての問い合わせが認証局のOCSPレスポンダに送られると、認証局はステータスを示すOCSPレスポンスの中に該当するSCTを埋め込んで返します。Webサーバはそのレスポンスを保持しておきます。
このSCTが埋め込まれたOCSPレスポンスがTLSハンドシェイクの際にクライアントに送られ、クライアントはLogにその証明書情報が格納されているかどうかを確認することができるようになります。
認証局にとっては(1)のように証明書発行のロジックを複雑にする必要がないというメリットがある一方で、Webサーバ管理者は必ずOCSPステイプリングを有効にしなければならないというデメリットもあります。

上記3点を比較した場合、(2)と(3)はWebサーバ管理者による設定が必要で、結果的にWebサーバごとに対応にばらつきが出る可能性があります。今のところの現実解としては、認証局が(1)に対応するしかないであろうというのが、各認証局及びGoogleの考えているところです。

Googleはすでに、ChromeにおけるCTへの対応のロードマップについて以下のようにアナウンスしています。

• ・2015年1月を超える有効期限を持つ（発行済みも含めた）すべてのEV証明書の情報は、少なくとも１つのLogに登録されなければならない
• ・Googleは2015年1月1日に、発行済みのEV証明書でSCTが組み込まれていないもののホワイトリストを作成する
  (筆者注：つまりこの日以降に発行されるEV証明書についてはすべてSCTを取得しなければならないことを意味している）
• ・2015年2月1日をもって、Desktop版のChromeは、上記ホワイトリストに登録されておらず、かつCTに適応していないEV証明書についてはEV証明書であることの表示をしない。モバイル版ChromeについてはCTに適応していないEV証明書について、EV証明書であることの表示をしない。

上記を受けて、弊社を含めた各認証局は、現在EV証明書のCT準拠のための対応を行っています。

GlobalSignでは、2014年末までにEVの証明書についてCTへの対応を完了する予定です。
また、その他の証明書についても、2015年の上半期までに対応を完了する予定です。


参考資料：
Certificate Transparency
RFC6962



2014.07.26