[SSL] SSLサーバ証明書について考える

WebサーバとWebブラウザ間の通信を暗号化するためにはSSLと呼ばれるプロトコルを使用して通信を行います。このとき重要な役割をはたすのが、SSLサーバ証明書です。このSSLサーバ証明書、安いものは年間3000円程度のものから、高いものでは年間20万円程度のものまで様々です。根拠を提示せず「安い証明書で十分」という人もいます。本当にそうでしょうか？SSLサーバ証明書を選択する際の参考になればと思い、少し長くなりますがまとめてみました。

0. はじめに
1. SSLサーバ証明書とはなにか
2. 発行時の認証内容
3. 実際に発生した認証局のトラブル
4. SSLサーバ証明書をどのように選ぶか

インターネット黎明期もっともポピュラーであったSSLサーバ証明書はVeriSignのSSLサーバ証明書でした。VeriSignはSSLサーバ証明書に加えWebサイト用のシール（VeriSign Secure Seal）を提供していました。このシールをクリックすると、SSLサーバ証明書の詳細情報をわかりやすく説明しており実在証明が容易に確認することが可能でした。このシールをWebサイトに貼ることがステータスな時代もありました。時代は変わり、現在では様々な認証局がSSLサーバ証明書を提供しています。SSLサーバ証明書が安価になったことでSSLが使用される事が増えています。またHTTPの拡張仕様であるSPDYではHTTPSが必須となります。SSLサーバ証明書の違いを知って、活用いただければ幸いです。

SSLサーバ証明書はWebサーバに導入される電子証明書です。このSSLサーバ証明書の利用目的としては「通信の暗号化」「組織の認証」の２つがあります。

SSLサーバ証明書は、認証局とよばれる第三者の組織により電子署名されます。認証局が適切に運用されており信頼できる存在であれば、その認証局が電子署名したSSLサーバ証明書もまた信頼できるという考え方です。認証局ではSSLサーバ証明書に電子署名するに必要な秘密鍵を厳重に管理しています。この秘密鍵が漏洩した場合、不正に入手した人間・組織が秘密鍵を悪用し、不正なSSLサーバ証明書を発行することが可能になります(過去にそのような事件が発生しています)SSLサーバ証明書の目的についてもう少し見てみましょう。

SSLサーバ証明書の役割の一つは、クライアント・サーバ間で暗号化された通信を行うための役割です。
実際にSSL通信が開始されるまでの手順は以下の図の通りです。

1. 利用者側クライアントPC(以下クライアント)からWebサイト側サーバ(以下サーバ)に対してSSLの通信を要求
2. サーバからクライアントへ、SSLサーバ証明書およびサーバ公開鍵を送付
3. クライアントで、SSLサーバ証明書を、認証局のルート証明書に含まれる公開鍵で復号し、SSLサーバ証明書が正しいことを検証
4. クライアントで、共有鍵をランダムに生成
5. クライアントで、共有鍵をSSLサーバ証明書から取り出した公開鍵で暗号化する
6. クライアントからサーバへし、暗号化された共有鍵を送付
7. サーバで、暗号化された共有鍵をサーバ秘密鍵で復号し、共通鍵を取り出す
8. サーバとクライアント双方が保持する共有鍵を使用してその後の通信を行う

このように、暗号化通信に使用する共有鍵をやり取りするためにSSLサーバ証明書は重要な役割を果たします。

SSLサーバ証明書のもう一つの役割は、通信先のWebサーバの運営主体の組織を認証することです。クライアント・サーバ間が暗号により安全に通信されたとしても、その相手先が正しい組織でなくては情報が漏洩します。

運営主体が「実在する組織」であることを民間が運営する第三者の認証局が認証します。

1. 利用者が認証局を信頼する(Webブラウザ内には信頼された認証局の証明書および公開鍵が格納されている)
2. 認証局がWebサイトの運営組織を信頼する(認証局の暗号鍵で、SSLサーバの公開鍵を作成する)
3. 利用者が信頼する認証局が信頼するWebサイトは信頼できる(Webサイトの証明書および公開鍵を、認証局の公開鍵で検証する)

Webブラウザには、適切に運用されている主要な認証局のルート証明書が複数導入されています。Webブラウザはこのルート証明書を利用して、SSLサーバ証明書がどのルート証明書で認証されたかを確認します。万一認証局の運用で問題が発生した場合には、特定の証明書やルート証明書を停止するなどの措置が取る事により、不正な証明書が利用できなくなる仕組みを備えています。

ルート証明書の作成手順は公開されており、誰でも作成が可能です。同様にルート証明書を利用してSSLサーバ証明書をすることも可能です。

ブラウザ内に含まれていないルート証明書で電子署名されたSSLサーバ証明書の場合どのようになるのでしょうか。

たまに見かけるドキッとする画面ですね(笑)

Webブラウザに登録されていないルート証明書で電子署名されたSSLサーバ証明書は、Webブラウザから見た場合信頼出来ない認証局で認証されたSSLサーバ証明書となります。信頼できない認証局で証明されたSSLサーバ証明書は信頼出来ないため、接続時にはユーザーに警告されます。

（なおこの状態のSSLサーバ証明書をオレオレ証明書を呼ぶことがあります）

認証局がSSLサーバ証明書を発行する際には、その申請者が正当な申請者であることを確認することが求められます。確認手順として大きくわけて2種類の方法が取られます。

• ドメイン認証は、そのドメインの使用する権利があるかを確認します。ドメイン認証の電子証明書は以下の手順で発行されます(GeoTrustの例)
  • 申請者が発行申請を行います。
  • 証明書発行の意思確認のメールを送付します
  • メール記載のURLから申請内容を確認し、証明書発行を承認します。
  • 申請者がドメインの使用権があることを確認し、証明書が発行されます。

実際にドメイン認証で発行された証明書は以下のようになります(上IE9、下Chrome)。

証明書をみると、IEの発行先やChromeの組織の欄にはドメイン名が記載されます。この証明書からはどのドメインに付与されたSSLサーバ証明書なのかは判別できますが、どの組織に付与されたSSLサーバ証明書なのかは判別できません。

• 組織認証では、そのドメイン名を使用する権利があるかを確認に加え、組織が実在しているかを確認します。企業の存在確認のために、第三者（帝国データバンク等）に照会します。組織認証の電子証明書は以下の手順で発行されます(GeoTrustの例)
  • 申請者が発行申請を行います。
  • 申請された組織情報とドメインのWhois情報と照合し、申請者とドメインの組織が同一であることを確認します。
  • 組織情報を第三者（帝国データバンク等）に照会し、実在していることを確認します。
  • 第三者情報の代表電話番号に電話にて、申し込み意思確認を行います。

組織認証で発行された証明書は以下のようになります(上IE9、下Chrome)。

証明書をみると、IEの発行先やChromeの組織の欄にはそのドメインを運営する組織名が、記載されます。この証明書からはどの組織に付与されたSSLサーバ証明書なのかわかります。ただし証明書を表示しないでブラウザの表示だけでドメイン認証との区別することは難しいです。

• EV組織認証では、ドメインの使用権利の確認、組織の実在の確認に加え、組織の物理的存在確認、組織の運営確認、承認者・署名者の確認を行います。EV組織認証では、業界で定められた厳密な認証手順により認証が行われます。大まかな流れは組織認証と同様ですが、追加で書類が必要となることがあります。

EV組織認証で発行された証明書は以下のようになります(上IE9、下Chrome)。

証明書をみると、IEの発行先やChromeの組織の欄にはそのドメインを運営する組織名が、記載されます。この証明書からはどの組織に付与されたSSLサーバ証明書なのかわかります。さらにブラウザのアドレスバーが緑色になり、アドレスバー内にも組織名が記載されますので一般の利用者にもわかりやすいです。

	ドメイン認証	組織認証
発行時に審査される内容	ドメイン所有の名義	ドメイン所有の名義 第三者照合 申請者の在籍確認
発行にかかる日数	数時間	数日
信頼性	SSL通信OK (ドメインを所有していればだれでも取得できる)	SSL通信OK 第三者による申請組織の存在確認

ドメイン認証はテストサイトや個人〜中小企業で、組織認証は中小企業〜大企業やネットショップ等で、EV組織認証はフィッシングの被害を受けやすい大企業や大手ショッピングサイト、銀行・カード会社等お金を扱う企業、大規模なWebサービスを提供する企業で利用される傾向にあります(FacebookやTwitterといった大規模なSNSサイトでは実際にEV認証が利用されています。)。なりすましのリスクに応じて、ドメイン認証→組織認証→EV認証を使いわける必要があります。

上記の証明書の例のようにドメイン認証の場合には、運営する組織名がわかりません。従って第三者がなりすましてドメインを取得しドメイン認証のSSLサーバ証明書を取得した場合には、正しい組織が運営しているのか否かを見抜くことはできませんので注意が必要です。

信頼性が求められる認証局ですが、その認証局でも様々なトラブルが発生しています。実際にどのようなトラブルが発生したか見ていきます。

• Comodo(イギリス)での不正なSSLサーバ証明書発行事件
  2011年3月にComodoが委託するイタリアの登録局に不正侵入され、偽造SSLサーバ証明書が9件(login.live.com、mail.google.com、login.yahoo.comなど)発行されました。この事件への対応として、Webブラウザベンダーは偽造されたSSLサーバ証明書が利用できないよう自動的にブロックするアップデートを公開し対応しました。
• StartSS(イスラエル)への攻撃事件
  2011年6月にStartSSは攻撃を受け、一時SSLサーバ証明書の発行業務を停止しました。
• DigiNotar(オランダ)での不正なSSLサーバ証明書発行事件
  2011年7月にDigiNotarに不正侵入され、発行するための情報が流出、少なくとも531件の偽造SSLサーバ証明書が発行されました。実際にgoogle.comを含む偽造SSLサーバ証明書が発行され、イラン国内のGoogleユーザーに対して盗聴が行われた可能性があったとのことです。この事件への対応として、Webブラウザベンダーは偽造SSLサーバ証明書が利用できないよう自動的にブロックするアップデートを公開し対応しました。さらにDigiNotarのルート証明書(証明書ツリーの中心となる証明書)をWebブラウザ側で失効・削除としたため、オランダ政府サイトや金融機関などのWebサイトへのアクセスもできなくなりました。ルート証明書を失効・削除されたDigiNotar社は事業継続できなくなり破綻しました。

偽造SSLサーバ証明書が発行され、その偽造SSLサーバ証明書を利用して偽サイトを構築しそのサイトに誘導された場合にはブラウザ上で正しいSSLサーバ証明書と偽造SSLサーバ証明書を区別することは極めて困難です。したがって偽サイトを見破ることも困難となります。

参考記事：
SSL認証局が偽の証明書を発行、大手サイトに影響の恐れ – ITmedia エンタープライズ
http://www.itmedia.co.jp/enterprise/articles/1103/24/news020.html
SSL認証局を狙った攻撃がまた発生、証明書の発行を中止 – ITmedia エンタープライズ
http://www.itmedia.co.jp/enterprise/articles/1106/22/news071.html
認証局が不正なSSL証明書を発行、Googleユーザーを狙う攻撃が発生 – ITmedia エンタープライズ
http://www.itmedia.co.jp/enterprise/articles/1108/31/news017.html
証明書偽造事件からの信頼回復への取組み～ インターネットの安全性を守るために ～
http://www.ipa.go.jp/security/event/2012/ist-expo/documents/preso_10.pdf

4. まとめ：SSLサーバ証明書をどのように選ぶか