インターネットの利用が普及した現在、その利用方法で最も一般的なものとして挙げられるのはWebとメールだろう。言い換えれば、インターネットを利用するアプリケーションの中で、最も普及しているのはWebブラウザとメーラである。Internet Explorer（以下、IE）やNetscape Navigator（以下、NN）などのメジャーなWebブラウザのほとんどが「SSL対応」という形で、また、OutlookやNetscape Messengerといった主要なメーラは「S/MIME対応」という形でPKIの実装がなされている。
今回は、この最も身近なPKIの実装ともいえるSSLについて見ていきたい。
“セキュア”な通信を実現するSSLとは？
SSLとはSecure Sockets Layerの略で、Netscape Communications社が提唱しているプロトコルだ。現在その仕様はVersion 3.0となっており、Netscape Communications社のWebサイトで公開されている。
もともとSSLは、その名が示すとおりプロセス間のソケット通信を“セキュア”にするために考えられたもので、その適応範囲はWebにとどまるものではない。しかし、現状はWebにおける認証および通信の暗号化に最も多く使用されている。
SSLは実際にTCP/IPの上で実現され、その上でHTTPやLDAPなどのアプリケーションプロトコルが動く形になる（図1）。
SSLで実現できる機能としては、以下の3つがある。
(1)サーバ認証
(2)クライアント認証
(3)セッションの暗号化
(1)、(3)を実現するためにはサーバ側に秘密鍵と公開鍵のキーペアおよびそれに対する証明書が、(2)を実現するためには、さらにクライアント側にもキーペアおよびそれに対する証明書がそれぞれ必要になる。
実際にはそれぞれを独立して実装することはできず、(1)と(3)の組み合わせか、(1)から(3)のすべてを実装するか、どちらかの選択を行うことになる。業務的なニーズとしてはHTTPセッションを暗号化したいというニーズが圧倒的に多く、それを実現するために(1)と(3)の組み合わせを取っているパターンが一番多いようだ。
SSLの実現〜サーバ認証
先ほども書いたように、SSLのサーバ認証は文字どおりサーバの認証を行う機能と、セッションの暗号化機能がある。Webの環境でこれを行うためには、Webサーバ側に秘密鍵と公開鍵のペア、およびそれに対応する証明書が必要になる。MicrosoftのInternet Information Server（IIS）を例にとって、キーペアの生成から証明書のインポート、SSLの設定までを見てみよう。
IISではインターネットサービスマネージャを使って設定を行う。
(1)左側の「コンソールルート」から、申請するWebサイト名を右クリックし、「プロパティ」を選択する
(2) 「ディレクトリセキュリティ」タグを選択し、「セキュリティで保護された通信」の「編集」ボタンをクリックする
(3) 「キーマネージャ」ボタンをクリックして起動する（画面1）。キーマネージャ画面のメニューから、「キー」→「新しいキーの作成」を選択する
(4) 実際の鍵ペア生成の前に、認証機関に送るCSRファイルの情報を入力する。「証明書機関に送付するファイルに要求を添付」を選択し、CSRファイルの保存場所を指定する
(5) 任意の「キー名」「パスワード」を入力し、「次へ」をクリックする
(6) 組織名以下の情報を入力する。ここで入力した情報が最終的に証明書に入る情報となる。なお、「コモンネーム」はドメイン名を含むサーバ名を入力する
(7) 「完了」ボタンをクリックする。自動的にキーペアが生成され、CSR（Certificate Signing Request：証明書要求）ファイルが作成される
これでキーペアの生成が完成し、証明書要求の準備ができたことになる。
なお、ボルチモアテクノロジーが提供するWebサーバ用証明書「SureServer」では、30日間の無料トライアル版を発行している。Webページに上記で作成したCSRをコピー＆ペーストして送信するだけなので、ぜひ試していただきたい。詳細はボルチモアテクノロジーのホームページを参照してほしい。
さて、証明書の入手ができたらそれをIISにインポートする必要がある。証明書のインポートの手順は以下のとおりだ。
(1)「キーマネージャ」の画面で、先に生成したキーを選択し、右クリックする
(2) ポップアップメニューから「キー証明書のインストール」を選択する
(3) 証明書ファイルを選択する
(4) キー生成時に設定したパスワードを入力する
(5) 申請したWebサーバの「IPアドレス」を入力する。「ポート番号」には通常、443を指定する。「OK」ボタンをクリックする
また、上記の証明書を発行した認証局の証明書もインポートする必要がある。以下が認証局の証明書のインポート手順だ。
(1)CA証明書のファイルをダブルクリックすると、CA証明書が表示される。ここで「証明書のインストール」ボタンをクリックする
(2) 証明書マネージャのインポートウィザードが表示されるので、「すべての証明書を次のストアに配置する」を選択し、「参照」ボタンをクリックする
(3) 「物理ストアを表示」→「中間証明機関」→「ローカルコンピュータ」→「OK」とクリックする
さて、証明書のインポートが終了したら最後はSSLの設定を行う。SSLの設定はインターネットサービスマネージャの「セキュリティで保護された通信」ダイアログボックスで「このリソースにアクセスするときに、セキュリティで保護されたチャネルを必要とする」にチェックを入れるだけだ。サーバ認証であれば「クライアント証明書の認証」は「クライアント証明書を受諾しない」にチェックを入れておけばよいだろう（画面2）。
これで、SSLサーバ認証の準備は完了だ。あとはクライアントのWebブラウザからそのサイトにアクセス（その際はURLの入力を「https://」で始めなければならない）して、実際にSSLで通信が行われていることを確認する。
また、この際、画面3のようなメッセージが現れることがある。これは、Webブラウザがサーバの証明書を発行した認証局が信頼できるかどうか判断できないために表示されるものだ。独自に立てた認証局など、Webブラウザにあらかじめ設定されている以外の認証局（先のSureServerトライアル版も同様）からサーバ証明書を発行している場合、その認証局を「信頼できる証明機関」のリストに追加する必要がある。以下がその手順だ。
(1)CA証明書のファイルをダブルクリックすると、CA証明書が表示される。ここで「証明書のインストール」ボタンをクリックする
(2) 証明書マネージャのインポートウィザードが表示されるので、「証明書の種類に基づいて、自動的に証明書ストアを選択する」を選択する
(3) 「次へ」→「完了」をクリックする
画面4（左：IE）・5（右：Netscape） Webブラウザに表示されるマークが、それぞれ上記の状態になっていれば、セッションが張られている状態であることがわかるSSLのセッションが張られたかどうかは、IEなら右下に鍵マーク（画面4）が現れること、NNなら左下の鍵マーク（画面5）が閉じた状態になっていることで確認できる。ちなみに、この鍵マークをダブルクリック（NNならシングルクリック）することによって、サーバ側の証明書の内容を確認することが可能だ（画面6・7）。
SSLの実現〜クライアント認証
さて、今度はクライアント認証まで行う場合について見てみよう。
まず、サーバ側でクライアント認証を行う旨の設定をする。設定の方法は、サーバ認証のときに使用したインターネットサービスマネージャの「セキュリティで保護された通信」画面で「このリソースにアクセスするときに、セキュリティで保護されたチャネルを必要とする」にチェックを入れ、さらに「クライアント証明書の認証」の「クライアント証明書を要求」にチェックを入れる必要がある。このような設定がされたサイトにアクセスすると、IEであれば証明書を選択するための画面が表示される。この選択画面に表示される証明書は、クライアント側にインストールされている証明書のうち、サーバ側で「信頼する認証機関」として登録している認証局から発行されたものだけである。もし該当する証明書が1枚もクライアントにインストールされていない場合、証明書選択画面は表示されるが候補の証明書が1つもないという画面が表示されることになる。
すなわち、サーバ側が信頼していない認証局から発行された証明書を持っていても、そのサーバにはアクセスできないということだ。
SSLのクライアント認証の一番基本的な部分は、このように「クライアントがサーバの信頼する認証局から発行した証明書を持っているか否か」のチェックを行うものである。ただし、（旧Netscapeの）iPlanetのWebサーバとディレクトリサーバの組み合わせでは、ディレクトリサーバ上に格納されている証明書とクライアントの提示してきた証明書が一致しているかどうかまでのチェックを行うことができる。
また、IISであればASP（Active Server Pages）を使ったサーバサイドのスクリプトによって、またiPlanetのWebサーバであればNSAPIを使用することによって、それぞれ証明書の情報を取得することができる（図2）。上記のWebサーバの下で動くアプリケーションがユーザーの情報を取得し、後続の処理を振り分けたいなどのニーズは多いだろうから、このような形で証明書の内容を取得できることは非常に重要だろう。
SSLの仕組み
ここでSSLのプロトコル仕様のすべてを紹介することは不可能なので、セッションを確立するためのHandshake Protocolについてのみに触れることにする。
Handshake Protocolとは、SSLの中でセッションを開始あるいは再開するために用いられるプロトコルで、認証に必要な証明書情報や、セッションで使用する暗号化のアルゴリズムなどをクライアントとサーバの間でやりとりするためのプロトコルだ。
具体的には、以下のメッセージがやりとりされる（図3）。
(1) Helloメッセージ
このメッセージでは、クライアントとサーバの間で使用する暗号化アルゴリズムなどの情報を交換する。具体的には以下のメッセージがある
- Hello Request
サーバからクライアントに送信される。Client Helloを要求するメッセージで、受け取ったクライアントは直ちにClient Helloメッセージを送信しなければならない - Client Hello
クライアント側が、最初にサーバに接続するとき／上記のHello Requestをサーバ側から受け取ったとき／既存のコネクションにおいて暗号化パラメータなどを変更するときにサーバ側へ送信する。内容は使用される暗号化方式やデータの圧縮方式に関する、候補のリストが格納された形になっている - Server Hello
Client Helloに対するサーバ側の応答メッセージ。Client Helloのメッセージで示された暗号化方式と圧縮方式のリストから、どれを使用するかを指定する
(2)Server Certificateメッセージ
サーバからクライアント側に送られるメッセージ。サーバ側は自分の証明書をこのメッセージを使用してクライアント側に送付する。また、ここにはその証明書を発行した認証局の証明書や、さらに上位の認証局があればその証明書といった形で、ルート認証局までの証明書チェーンをすべて含んだリスト形式で送信される
(3)Server Key Exchange
サーバが証明書を持っていない場合、あるいは持っていても署名にしか使用できない場合に、サーバ側からクライアント側に送信されるメッセージ
(4)Certificate Request
クライアント認証を行う際に、サーバ側からクライアントの証明書の提示を要求するためのメッセージ。このメッセージに、サーバ側が信頼する認証局のリストが付加されている
(5)Server Hello Done
サーバ側からクライアントに向けた一連のメッセージが送信されたことをクライアント側に通知するためのメッセージ
(6) Client Certificate
クライアント認証を行う場合にクライアント側が自分の証明書をサーバに送信するためのメッセージ。データの形式はServer Certificateと同様
(7) Client Key Exchange
セッションで暗号化のために使用される鍵（セッションキー）を生成するときに使用されるマスタシークレットを生成するもとになる、プリマスタシークレットデータを、クライアント側から送信するためのメッセージ。RSAの場合、プリマスタシークレットデータはサーバの公開鍵で暗号化される
(8) Certificate Verify
クライアントからサーバに送信される。サーバ側がクライアントの認証を行うために必要なデータを送信する。具体的には双方が既知のデータのハッシュ値をとり（SHAとMD5双方のアルゴリズムが用いられる）、クライアント側の秘密鍵で暗号化したもの。サーバ側でこれをクライアントの公開鍵で復号し、同じように取得したハッシュ値と比較することで検証を行う
(9) Finished
クライアント側、サーバ側双方とも、相手の認証が正常に行われたことを相手に知らせるためのメッセージ
このような形で相互の認証が行われた後、双方でプリマスタシークレットデータから最終的にセッションキーが生成され、暗号化が施されたセッションが開始されるという手順になっている。
冒頭にも書いたが、おそらくSSLが今最も広く使用されているPKIの実装形態であると思う。そのような意味で、SSLはPKIを「実感」するためのよい教材となるであろう。今後、ブラウザの「鍵マーク」が閉じられたサイトがあったら、ぜひマークをクリックして、サーバ証明書の内容をのぞいてみてほしい。
Copyright © ITmedia, Inc. All Rights Reserved.