CT（Certificate Transparency：証明書の透明性）の現状

CT（Certificate Transparency：証明書の透明性）が目指すゴールは、それぞれ独立で運営している会社のパブリックなログサーバーで、すべてのSSLサーバ証明書を複数参照できるようにすることです。
その上で、ブラウザがログサーバーに登録されていると認証されたものだけを正しい証明書として信頼するという仕組みが成立することを目指しています。
そこまで到達することができれば、ドメインオーナーや情報が必要な組織は、ログをモニターし、認証局（CA）によって誤発行された証明書や、認証局が認証していない不正な証明書を発見できるようになります。

CT（Certificate Transparency：証明書の透明性）の成功には、以下のような代表的組織に加え、数多くの関連する組織の協力が必要です。

DigiCertは、発行された証明書が本当にドメインやブランドの所有者が申請し取得したものなのかを検証する新たな手法の確立を強力に支援します。
CTは、発行済み証明書に対する検証方法として唯一のものであり、OVタイプの検証におけるキーコンポーネントであり、CAブラウザフォーラムのガイドラインで提唱されている「必要に応じた検証の仕組み」にも対応できるものであるとDigiCertは考えています。

CT（Certificate Transparency：証明書の透明性）の実現化には、全ての認証局（CA）が CTを発行できるようにする必要性があります。そして、可能ならば全ての証明書がデフォルトでCTで発行されるべきだと考えています。
しかし、CAやブラウザのCTへの対応／非対応による混乱を避ける手段として、Googleは、段階的な導入を計画しています。
CT対応の第一段階は、EVサーバ証明書に対してのみ「 CT（Certificate Transparency：証明書の透明性）」を適用したものを発行します。
とはいえ、この第一段階であっても、ログオペレーターの不正や間違い対策として、独立した複数のログサーバーが十分に機能している必要があります。

Chromeが2018年4月30日以降に発行されるすべてのSSL/TLSサーバ証明書でCTを必須に

Chromeでは、2018年4月30日以降に発行されたCT（Certificate Transparency：証明書の透明性）に対応していないSSL/TLSサーバ証明書を利用しているWebサイトに接続する際、当該サイトの証明書がCTに対応していないことを示す警告が表示されます。
これに対応するため、2018年4月30日以降に発行するすべてのサーバ証明書は、CT（Certificate Transparency：証明書の透明性）に対応している必要があります。

TLS証明書にSCTを埋め込んで発行する認証局（CA）は、Chromeで警告が表示されないようにするために、Chromium CTポリシーで証明書の資格要件に準拠していることを確認する必要があります。
このCTコンプライアンスの実施は、2018年4月以降に発行された証明書にのみ適用されます。それ以前に発行された証明書は影響を受けません。

認証局（CA）は、OCSP CT拡張内にOCSP応答でSCTを含めることを選択することができます。ただし、Webサイト運営者が常にこれらのOCSP応答をステープルする場合にのみ、RFC 6962およびChromium CTポリシーの準拠が許可されることに注意してください。
さらに、ステープルされたOCSPレスポンスに含まれるSCTには、証明書に組み込まれたSCTとは異なる要件があり、CAにシステムの迅速な変更を要求する場合があります。
CAがこれらの変更を行うことができない場合、またはサイト運営者が新鮮なOCSP応答をステープルできない場合、その証明書は機能しなくなります。
このため、CAはSCTを発行するTLS証明書にSCTを組み込むことを推奨します。

CT（Certificate Transparency）の背景と歴史

2011年に、DigiNotarと呼ばれているオランダの認証局（CA）がハッキング行為を受けました。
そして、ハッキングを行ったハッカー達が、DigiNotarのルート証明書をもって発行されたように見せかけた500以上の不正な証明書を偽造したのです。
ハッカーたちは、これらの偽造証明書を使い、多数の偽装サイトを作成しました。
この偽装ではGoogleとFacebookも標的となり、ハッカーたちは証明書を疑うことのないWebサイトユーザーに対して中間者攻撃を行ったのです。

この事件が、Googleのエンジニアたちに証明書の偽装に関する新しい解決策の確立を迫りました。
Googleは議論の末、ベン・ローリーとアダム・ラングリーという二人のエンジニアが考えたCT（Certificate Transparency：証明書の透明性）のアイディアを、オープンソース・プロジェクトとして開始しました。
ローリーとラングリーは2012年、IETFグループと共にこの仕組みの草案を作成し、2013年にRFC 6962の仕様となりました。

2013年、Google は2つのパブリックなログの運用を始め、Google Chromeブラウザでは、全てのEV SSLサーバ証明書を、このログでCT検証させる計画を発表しました。

2015年1月現在のログ／ブラウザ／認証局（CA）の対応状況

ログ

2014年12月現在、Chromeブラウザでは、Googleのログサーバーを利用した2つのログを参照します。近く、3つ目のログ参照も予定しています。
3つ目以降のログサーバーとしては、Googleのもう1つと、DigiCert、Izenpe、CertlyGoogleのログが準備中ですが、DigiCertのログは、近く稼動予定です。

他の2社（Izenpe、Certly）のログは、2015年第一四半期以降に稼動予定となっています。
ログの登録・運営には高い信頼性が求められ、90日間のテスト期間が課せられています。
テストにより必要条件を満たせていないと判断されたログは、信頼できないログということになります。従って、DigiCertもログ構築には特別の注意を払っています。

Googleでは、

• 1年間有効な証明書に対しては2つの別々のログから
• 2間有効な証明書に対しては、少なくとも3つの個別のログから

CT検証が必須となります。
認証局（CA）側の移行対応を容易にするために、Googleは2015年7月まで一時的に独立したログについて、【Googleの2つのログ】と、【DigiCertから1つのログ】から検証できればよいとしています。
暫定期間中に、認証局（CA）と、セキュリティに関心のある会社が、より多くのログサーバーを構築し、実稼動できる充分な数のログサーバーを整備することが求められています。

ブラウザ

認証局（CA)

2015年1月1日までに、主要な認証局（CA）全てが、 CTログサーバーへのEVサーバ証明書発行の登録を開始します。
2年間有効なEVサーバ証明書を発行する認証局（CA)はいずれもGoogleが要求している条件を満たすために、Googleの2つのログと、DigiCertのログを利用することが出来ます。
多くの認証局が、近い将来のログの設置を予定しています。

CT（Certificate Transparency）に関するDigiCertの取り組み

DigiCertでは2012年からCT（Certificate Transparency：証明書の透明性）のシステム化の実験を行い、その評価をCT実装提案としてフィードバックしてきました。
そして2013年9月、DigiCertはCTを実装した最初の認証局（CA)になりました。
同年10月には、証明書発行を希望する顧客に対して、CT埋め込みオプションを提供する最初の認証局（CA)となったのです。

DigiCert は、CT（Certificate Transparency：証明書の透明性）ログを構築した、最初の認証局（CA)です。
構築したログは、2014年9月、Googleに提出しました。
URLは https://ct1.digicert-ct.com/log/ です。
二つめのURLは https://ct1.digicert-ct.com/log/ です。
（このURLは、ブラウザからはアクセスできません。）