Lesson4では,通信相手のサーバーが信頼できるかどうかを確認するしくみを見てみよう。ここでは,サーバーがクライアントに送信する「サーバー証明書」に注目する。

証明書には「署名」が付いている

 サーバー証明書は,サーバーの管理者が,「認証局」と呼ばれる組織に申請して発行してもらう(図4-1)。サーバー証明書には,サーバー運営者の組織名,認証局の組織名,証明書の有効期限,サーバーの公開鍵などの情報が書き込まれている。さらに,サーバー証明書には認証局の署名が付いている。署名とは,証明書の内容をハッシュした値を,認証局の秘密鍵で暗号化したデータである。

図4-1●「サーバー証明書」と「署名」とは?
図4-1●「サーバー証明書」と「署名」とは?
サーバー証明書は,サーバーの各種情報が書き込まれた情報で,サーバーの公開鍵が含まれている。サーバー証明書には,認証局の署名(証明書を認証局の秘密鍵で暗号化したデータ)が付いている。
[画像のクリックで拡大表示]

 Lesson2で説明したように,公開鍵暗号方式では,一方の鍵で暗号化したデータは,ペアとなっているもう一方の鍵でしか復号できない。公開鍵で暗号データを正しく復号できた場合,その暗号データはペアとなっている秘密鍵を使って暗号化されたことが保証される。秘密鍵は,所有者だけが持っているはずなので,これによってその証明書は認証局が発行した証明書であることがわかる。

実際は複数の証明書が送られる

 ただし,クライアントにしてみると,その署名を施した認証局がそもそも信頼できるのかが気になる。

 実は,サーバー証明書と一緒に,署名を施した認証局の証明書もクライアントに送られている。もし,その認証局が他の認証局から署名を受けている場合は,さらにその署名を受けた認証局の証明書も付けて送られる。こうして,最終的には一番上位に位置する「ルート認証局」と呼ばれる認証局の証明書が必ず送られてくる。そこでまずクライアントは,「そのルート認証局が信頼できるか」を確認する。

 その確認方法は簡単だ。実は,パソコンにはあらかじめ,信頼できるルート認証局の証明書(自己証明書)が複数インストールされている。クライアントは,そのあらかじめ入っている証明書と,サーバーから受信した証明書が一致するかを確認し,一致したら受信した証明書は信頼できると判断する。ルート証明書が信頼できたら,ルート証明書の中にある公開鍵を使って,ルート証明書から署名を受けた証明書を検証する。この流れで,受信したすべての証明書を検証する。

 証明書の検証の実際の流れを見てみよう。ルート認証局から署名を受けたサーバーが,クライアントにサーバー証明書を送信した例である(図4-2)。

図4-2●サーバー認証のしくみ
図4-2●サーバー認証のしくみ
クライアントには,「サーバー証明書」と「ルート認証局の自己証明書」が一緒に送られてくる。パソコンの中にもともと入っている証明書を使ってルート認証局の自己証明書の正当性をチェックし,その後,サーバー証明書の正当性をチェックする。
[画像のクリックで拡大表示]

 クライアントにはサーバー証明書とルート認証局の証明書が送られてくる。クライアントは,自分にインストールされている「信頼できるルート認証局の証明書」をチェックし,その中に一致する証明書があったら,そのルート認証局の証明書は信頼できると判断する(図4-2の(1))。

 次にクライアントは,ルート認証局の証明書の中に入っている公開鍵を使って,サーバー証明書に付けられた署名を検証する。具体的には,「署名をルート認証局の公開鍵で復号したデータ」と「サーバー証明書のハッシュ値」が一致するかどうかを確かめる。一致すれば,そのサーバー証明書は,確かにルート認証局から署名を受けたサーバー証明書であることがわかる(同(2))。

 これで,サーバー証明書が信頼できることがわかった。ということは,サーバー証明書の中にある公開鍵も信頼できることになる(同(3))。クライアントはこの公開鍵を使って,SSL通信を実行するわけだ。