| CTとは | CTのしくみ | CTの実現 | CTの現状 |
主要な認証局（CA)は、2015年1月1日までに、EV SSLサーバ証明書用として、「CT（Certificate Transparency：証明書の透明性）」のログ登録ができるように準備しなければなりませんでした。
しかし、いくつかの認証局（CA)では、EVサーバ証明書でない一般の証明書についてログ登録しているかもしれないなど、ログ登録に使うメカニズムは認証局（CA)ごとに異なります。
DigiCertでは、発行する全てのSSLサーバ証明書が、CT対応となっています。
認証局（CA)は、自社のルート証明が含まれているログであれば、どのログへも証明書を記録することが可能です。ログは証明書の登録要求受付とSCT（Signed Certificate Timestamp：登録済み証明書タイムスタンプ）情報を返します。
SCT（Signed Certificate Timestamp：登録済み証明書タイムスタンプ）
SCTは、証明書がMaximum Merge Delay（MMD）と呼ばれる所定の時間内にログサーバーに登録されることを示す登録予約証のようなものです。
Maximum Merge Delay (MMD) は24時間で、新規に発行された証明書は、SCTが作成されてから24時間以内にログサーバーに登録されるということになります。
この仕組みによって、証明書の発行が遅れたり利用が妨げられたりすることはありません。
SCTは、証明書が存在している限り証明書に含まれ、TLSハンドシェークの一部を構成します。
TLSハンドシェークのプロセスは、CTログを毎回参照し、SCTに誤りがないことを確認します。
CTでのSCT付き証明書の提供には「証明書への埋め込み」「TLS拡張機能の利用」「OCSP Staplingの利用」の3種類の方法があります。
DigiCertでは、現時点で3種類すべての方法でSCTの提供が可能です。
デフォルトでは、Google の2つのログサーバーと、DigiCertのログサーバーに登録されているSCTを埋め込んだ証明書を発行します。
この方法で証明書を発行する場合にはサーバー管理者側の作業は発生しません。
TLS拡張機能の利用、またはOCSP staplingを利用したい場合は、お問合せください。
認証局（CA）が発行する証明書の拡張機能部分に直接SCTを埋め込んで添付する方法です。
この方法では、サーバー管理者側では、サーバーの設定変更や、特別な対応作業も必要としません。
しかし、認証局（CA)の負荷として、証明書を交付する前に、SCT の受信が必要になります。
なお、証明書の拡張機能部分に含まれたSCTは以下のように確認できます。
サーバー管理者がTLSの特別な拡張機能を利用し、SCTと証明書紐付け、外部に提示することができます。
この方法を使うと、証明書のデータサイズの軽減が可能です。また、認証局（CA)側の作業等が発生しません。
OCSP(Online Certificate Status Protocol) プロトコルを利用したOCSP StaplingでSCTを提示することができます。
この場合、認証局（CA）は証明書をログサーバーとサーバー管理者双方に発行します。
この方法の場合、認証局（CA)は発行した証明書をログサーバーに送る必要がありますが、SCTの受信を待たずに証明書の発行が可能になります。
またこの方法の場合、サーバー管理者は、サーバーがOCSP Staplingに対応できるように設定する必要があります。
・SSLサーバー証明書
・コードサイニング
その他証明書
・バウチャ(クーポン)
