Let’s EncryptがVerisignと棲み分けできる理由: SSL証明書の「DV、OV、EV」とは何か

こんにちは、hachi8833です。

無料でSSL証明書を発行してくれるLet’s Encryptが大人気を博していますが、Verisignを始めとする有料の認証局(CA)はやきもきしていたり刺客を差し向けていたりしないのでしょうか?

そのあたりを弊社インフラエンジニアのyamasitaさん、そしておなじみmorimorihogeさんとbabaさんが解説してくれました。

160921_1555_CXabHS

証明書のランク分け: DV、OV、EV

SSLなどで使われる証明書の種類として、DV(Domain Validation)、OV(Organization Validation)、EV(Extended Validation)の3つがあります。

ざっくり言うと、後者になるほど値段も張り、取得の手続きも面倒になる(登記簿などの提出が必要)代わりに、証明書の信頼性が向上します。ただし信頼性と言っても社会的な手続き上の信頼性という意味であり、暗号強度などの技術的な面において違いはありません。

細かい点はシマンテックのサイトでもご覧いただこうかと思いましたが、さくらインターネットの説明が何だかとても見やすいのでこちらをおすすめします。

認証レベルをChromeブラウザで確認する方法

説明のため、認証レベルをブラウザで確認する方法をここで説明します。ここではChromeブラウザのみについて説明します。他にも確認方法はいろいろありますが、ここでは触れません。

ページが暗号化されていない場合

ページが暗号化されていなければ、アドレスバーの[i]アイコンが黒く表示されます。

160921_1647_8cAGDy

念のため、アイコン > 詳細の順にクリックしてみると、開発コンソールの [セキュリティ] タブで「This page is not secure.」と表示されます(この後についても同じ手順で表示します)。

160921_1650_lhwkIF

サイトの構成によっては、ページによって暗号化されていたりされていなかったりする可能性もあります。

ページが暗号化されている場合

ページが暗号化されていれば、Chromeで鍵アイコンが表示されるとともに、https://のところが緑色になります。この動作は、DV、OV、EVいずれも共通です。

160921_1656_CPOvtj

DVとOVの違い

実はこの2つの違いはアドレスバーだけではわかりません。アドレスバーでは、DVとOVはいずれもhttps://が緑色かつ鍵マークが表示されます

そこから[i]アイコン > 詳細の順にクリックし、Security > View Certificate をクリックして、さらに [詳細な情報] を展開して、やっと確認できます。

↓この[サブジェクト名](変な訳ですね)に[組織名]が表示されていない場合、その証明書はDVです。

160923_1209_mIHzZY

逆に以下のAmazonの証明書のように [組織名] に組織名が実際に表示されている場合、その証明書はOVです。ここに名前を表示するために、結構なお金を払い、さまざまな書類を提出して審査を受ける必要があるわけです。

160923_1211_RXxtde

OVのためにせっかくお金を払ったのだから、ブラウザがもう少しわかりやすく表示してあげてもよさそうなものです。

なお、審査において提出の必要な書類は、証明書の発行元によって異なります。第三者データベースとして帝国データバンクを使うと、発行元によっては若干提出書類を減らせるらしいとのことです。

EVの場合

証明書がEVの場合、Chromeの表示ではっきり違いがあります。アドレスバーに以下のように組織の名前が表示されるのは、EVだけです。

160921_1846_FB1AUx

先ほどOVの場合「審査において提出の必要な書類は、証明書の発行元によって異なります」と書きましたが、EVでは審査に求められる項目・要件が「EV SSLガイドライン」として世界共通で定められており、発行元による審査方法の濃淡がないとされています。そのため、社会的信用として最もランクが高いことになります。

Let’s Encryptが有料証明書発行企業と競合しない理由

高い証明書には理由がある

Let’s Encryptを始めとする無料証明書サービスで発行される無料の証明書は、もっともランクの低いDVのみであり、ドメインについてしか証明されません

さらに、Let’s Encryptの証明書は3か月で切れてしまうので、証明書を定期的に自動更新する仕組みを導入しておかないと使い物になりません。

SSLの機能は大きく分けて「経路のend-to-end【暗号化】」と「通信の相手が正しいこと【認証】」の2つがありますが、Let’s Encryptを始めとする無料証明書サービスはDVランクであるため、基本的に前者の「暗号化」が目的であり、認証については最小限であるドメインレベルにとどまります。

※Let’s Encrypt利用の注意事項や激安SSLとの違いなどについては、次回TechRachoで記事にします。ご期待ください。

逆に、後者の「正当性の認証」については有料のOV証明書やEV証明書の方がはるかに手厚くなっています。有料のOV証明書やEV証明書を取得するにはさまざまな審査にパスする必要があります。

160923_1300_HFsh0X

そうしたコストや手間暇をかけてでもサイトの正当性を強化する意義は大組織ほど大きいため、有料証明書への需要は常に存在します。

参考: さくらインターネットとシマンテックのOV/EV SSL取得手続き

前述のとおり、証明書サービスによって細かな点は異なる可能性があります。EVが最終的に依拠するのは「EV SSLガイドライン」です。

さくらインターネット(https://ssl.sakura.ad.jp/attestation_level.htmlより):
160923_1453_yObnqL

160923_1454_tyefr0

シマンテック(https://www.symantec.com/ja/jp/page.jsp?id=ssl-compareより):
160923_1457_9D3VDW

登記証明などによる組織の実在性確認や、電話での意思確認はOVとEV共通ですが、EVにはさらに書類の提出(申請責任者確認書)が加わります。

深読み: Let’s Encryptに大物スポンサーが付く理由

Let’s Encryptには大物スポンサーがついており、しかもVeriSignこそありませんが中には証明書サービスらしき会社もちらほら見かけるので、単なる慈善事業で行われているのではないことがうかがえます。

弊社morimorihogeさんの見立てでは「非暗号化サイトで抜かれたパスワードが自社サイトでも使いまわされていたら、自社だけ暗号化していても引き続き脅威になりうるので、非暗号化サイトを根絶するために暗号化用のDVぐらいは無料で提供しようじゃないの(その分OVやEVではしっかり稼がせてもらいまっせ)」というモチベーションがあるのでは、とのことです【※個人の感想であり根拠はないです。違ったらごめんなさい。むしろ詳しい人ぜひ教えてください:morimorihoge】。

160923_1247_S8wtHL

私も、スポンサーの中にChrome(つまりGoogle)の名前を見つけて、このような背景は割とあるのではないかと勝手ながら思います。Googleは、他にもGmailに関連してメールのSSL/TLS化を進めるなど、自社だけでは対応できない&いつ終わるとも知れない困難なセキュリティ対策を推進しているからです。

まとめ

以上の理由から、Let’s Encryptを始めとする無料証明書サービスは有料証明書サービスとうまく棲み分けていることになります。

暗号化のためにDV証明書を無償で提供するLet’s Encryptは「お前ら、パンツぐらい穿けや」とWebサイトの最小限の身だしなみを勧めてくれているありがたい存在です。

生HTTP通信を排除する方向に向かいつつある昨今、Let’s Encryptを始めとするサービスがせっかく勧めてくれているパンツを穿き忘れて、忘れた頃にモロ出し呼ばわりされてはつまりません。

出かけるときは、忘れずに。

このサイトも、ついにパンツを穿くときが来たようだ(遠くを見る目)。

追伸

その後ご覧の通り当サイトもSSL化いたしました。

おまけ

AWSのCertificate ManagerならSSLが無料なうえ、3か月ごとの更新が不要です。Herokuでも無料SSLサービスをやってるそうです。

SSLは無料でも他が無料とは限りませんのでご注意。

160923_1258_2XrEgF

どちらの銀行か存じ上げませぬが、一日でも早くhttpsで接続したぐらいでエラーにならないようになって欲しいものです。

こぼれ話

yamasitaさんに教わった話。

SSLはどのタイプであっても取得には必ず独自ドメインが必要ですが、SSL証明書を取得した途端にcrt.shのようなサイトで簡単に検出できるようになります。

普通ならこれで何の問題もありませんが、新製品などのキャンペーンや宣伝活動なんかで独自ドメインを取得してそれを当日まで秘密にしておこうとしても、新製品情報を含むドメイン名がこうしたサイトで一瞬でバレてしまう可能性があるんだとか。ファンがこうしたサイトをクロールして回るというのは十分ありうることですね。油断もすきもなし。

関連記事

Ruby on RailsによるWEBシステム開発、Android/iPhoneアプリ開発、電子書籍配信のことならお任せください この記事を書いた人と働こう! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833 コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。 これまでにRuby on Rails チュートリアル第2版の半分ほど、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れてそれぞれ一部を翻訳。 かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。 仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。

hachi8833の書いた記事

週刊Railsウォッチ

インフラ

BigBinary記事より

ActiveSupport探訪シリーズ