1. SSL/TLSサーバ証明書の黎明期から現在まで

SSL/TLSサーバ証明書の黎明期から現在まで

  • このエントリーをはてなブックマークに追加

「電子証明書」の定義とは何か、ご存知でしょうか。簡単に言うと、電子証明書とは「公開鍵(とそれと対になっている秘密鍵)の持ち主を証明するもの」になります。 現在、SSL/TLSの用途に使用される証明書には、その「持ち主」をどのレベルまで審査して発行するかによって、DV(Domain Validation)・OV(Organization Validation)・EV(Extended Validation)という3種類が存在します。 今回は、それぞれの証明書がどのような背景をもって誕生してきたのかを解説したいと思います。

OVが当たり前の時代からDVの誕生へ

私がこの業界にかかわるようになった2000年当時、SSL/TLS証明書といえばOV、つまり企業認証タイプのものでした。証明書を取得するためには基本的には法人登記が必要で、人手による企業の実在性についての審査が行われるため、申し込んでから証明書発行までにも相当な時間がかかり、また非常に高価でした。このため、証明書の利用は金融機関や一部の大手ECサイトにとどまっていました。

このような当時の証明書の「常識」を打ち破ったのがDV、つまりドメイン認証タイプの証明書です。DVの証明書の発行に際しては、主体者(=鍵の持ち主)が、証明書に記載されるドメインを保有またはコントロールしていることを確認するだけのため、企業情報については一切審査を行わず、また証明書にも記載されません。ドメインの保有についての審査はシステム的に行われるため、基本的には人手による審査は不要です。このことは劇的に証明書発行にかかるコストを下げ、結果的に証明書の価格は当時のOVに比較して数分の一になりました。また、法人登記も不要なため、個人で事業を行っている人でもドメインさえ持っていれば証明書を取得することが可能となりました。

こうしてDV によって証明書取得のハードルが一気に下がることで、インターネット上でスモールビジネスを運営する人の間にも証明書の利用が広がり、SSL/TLSの普及に大きく寄与しました。 一方で、証明書取得のハードルが下がったのはフィッシングサイトの運営者にとっても同じことでした。ドメインさえ取得できれば、法人登記などしなくても、クレジットカード決済で証明書を取得することができる。身元を一切明かすことなく証明書が入手できるようになったのです。
「ブラウザに南京錠がかけられた絵が出ていれば安全なサイトです」というような(かなり極端な)案内がまかり通っていた時代のことでしたから、当然のことながら、今までOVの証明書を販売していた認証局や一部のブラウザベンダーからは、DV証明書に対する大きな懸念が示されました。

EVの誕生

特に問題視されたのは、ブラウザのユーザから見てDVとOVの見分けがつかないということでした。実際にサーバに設定されている証明書の内容を見れば見分けることは可能ですが、ほとんどのユーザはその方法を理解することはできません。審査レベルの大きく異なるDVとOVが、ブラウザを通してみるとまったく同じように見えてしまう。OVを主なビジネスとしている認証局を中心として、ブラウザベンダー側にこれを区別するようなユーザエクスペリエンス(UX)を実装してほしいという要求が上がるようになります。

ただ、当時は同じOVの証明書といっても、認証局ごとに審査方法が異なっていました。ブラウザベンダーとしては、組織の審査方法や審査レベルが認証局ごとに異なっている証明書(あるいは証明書設定されたサイト)を一律に「企業の実在性が確認された証明書(を使っているサイト)」として表示することには抵抗があります。そこで、2005年に発足したCA/Browser Forum (CAB Forum)のなかで、統一された厳密な企業及びドメインの審査基準を策定し、この基準にのっとって発行された証明書を使用しているサイトについては、ブラウザ上で明確に区別できるようにする(具体的には、アドレスバーをグリーンで表示する、あるいは証明書の中の組織名をアドレスバーに表示する)こととしました。

※SSLサーバ証明書の標準的な発行ガイドライン策定を目的に、2005年に結成された業界団体。電子認証事業者(認証局)およびインターネットブラウザベンダー、ソフトウェアベンダーを主な構成メンバーとする世界レベルのボランティアフォーラムで、電子証明書サービスをとりまく課題解決についての議論や業界ガイドラインを作成しています。

Google ChromeでのEV設定サイトの表示のされ方
Google ChromeでのEV設定サイトの表示のされ方

DigiNotar事件とBaseline Requirementsの策定、そしてSSL/TLSのさらなる普及へ

ところが、2011年に認証局や証明書の信頼性を揺るがしかねない大きな事件が発生します。 DigiNotarというオランダの認証局のシステムが侵入を受け、侵入者によってGoogleのドメインに対する証明書を発行されてしまったのです。さらに侵入者は、その証明書をイランにおけるGoogleサービスに対するman-in-the-middle アタック(中間者攻撃)に使用します。これによって、およそ30万人のGmail利用者が盗聴の被害をうけました。また、この事件の背後にはイラン政府が関与しており、Gmailの盗聴によってイラン政府は反体制勢力を特定し、大勢の人々を検挙したといわれています。

この事件を受けて、CAB Forumの議論の中心は「いかに間違った証明書の発行(mis-issuance)を防ぐか」という方向に移っていきます。そして、今まで各認証局が独自に策定していたDVやOVの審査方法について、最低限守るべき統一された基準を設け、証明書の設定項目や有効期間についても取り決めを行い、2011年の終わりにBaseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (通称Baseline Requirements)として発表します。

これによって、DVやOVも、どの認証局でもある程度統一的な基準のもとに発行されることとなりました。企業認証タイプの2つの証明書、OVとEVの違いは、大まかにいえば(一般には理解されにくい)企業審査の方法の厳密性の違いと、ブラウザでの表示のされ方の違いだけになったのです。

このように証明書の発行について厳密な基準が策定される一方で、その証明書を使用したSSL/TLS自体の普及も大きな課題となりました。2013年には複数の政府機関がインターネットのトラフィックを監視、保管していたことが判明し、プライバシーを守る手段としてインターネット上のトラフィックを暗号化することの重要性が改めて認識されました。このような背景から、SSL/TLSの普及を最重要課題と考える人々や組織によって、無償でDV証明書を発行するサービスが開始されました。

SSL/TLSの普及とブラウザの表示

しかし、DVによってSSL/TLSの普及が進んだといっても、企業認証タイプの証明書が不要かというとそういうことにはならないでしょう。例えば、自分のメインバンクから出されたメールにあるURLをクリックしたときに(もちろんクリックする前にわかるのが理想ですが)、そのサイトが本当に自分のメインバンクが運用しているものなのかどうかを知りたいというニーズはあるはずです。 現状のEV証明書に対するブラウザの表示が十分なものなのかどうかは疑問ですが、ブラウザユーザがパッと見てそのサイトの運営者を認識できるというのは非常に有用でしょう。

一方、Googleは、SSL/TLSの普及がある程度進んだことから、HTTPS接続をデフォルトとして考え、アドレスバーの表示方法を段階的に変更する計画を発表しています。 この中で、どのバージョンから実装されるのかは明記していませんが、将来的にはアドレスバーにはURL(あるいはFQDN)のみを表示するという方針を表明しています。これによって、DV/OV/EVいずれの証明書が設定されたサイトであっても、ユーザからの見え方は変わらないものとなる案が進められています。

SSL/TLSが十分普及したので、常に安全なインターネット環境を前提にHTTPS接続をデフォルトと考え、HTTPで接続しようとした際にワーニングメッセージを表示する、という考え方は十分理解できます。ただ、EVについて、今まで存在していたブラウザ上の表示を全くなくしてしまうことがユーザの利益にかなうものなのかどうかは議論の分かれるところではないでしょうか。SSL/TLSをとりまく環境は、業界の動向に伴い様々な変化が起こっています。こうした業界の最新情報はまたブログでお知らせいたします。

  • このエントリーをはてなブックマークに追加

この記事を書きました

浅野 昌和

浅野 昌和
所属:GMOグローバルサイン グループ技術開発本部
>>浅野 昌和の記事一覧