イケメンとラブレターで学ぶSSLの仕組み

はじめに

みなさんはSSL(Secure Socket Layer)が何だか、きちんと説明できますか？

「フォームが暗号化されて送られるやつでしょ？」
「ブラウザのURL欄とかに鍵マークが付いてたら安心なんだよねー」

・・・いや、そういうレベルじゃなくて、もうちょっと裏側の仕組みまで説明できますか？
まあ単純にWeb利用者としてなら、それぐらいの理解でも構わないかもしれませんが、開発者やサーバーの管理者としては落第点ですよね〜！ww

って、すいません、僕がこのあいだまで落第点でした・・・ m(_ _)m

実際、裏側の仕組みが分かってないとSSL関連の申請やサーバーの設定をするときに「CSR？中間証明書？秘密鍵？？※◎△$%！！？？」になってしまいます。
なので、技術者であれば今自分が何をやっているのか把握できるように、SSLの仕組みをきちんと理解しておくことが必要です。

というわけで、今回はイケメンとラブレターのたとえ話を使って、難しい専門用語なしにSSLの仕組みを説明してみたいと思います。
(すいません、かなり長文です・・・)

登場人物の紹介

このたとえ話に出てくる人物は二人です。
　

モテモテイケメン男性の伊藤さん(西脇市在住)
伊藤さんに憧れる独身OLサチコさん(同じく西脇市在住)

　
サチコさんは伊藤さんにヒミツのラブレターを送りたいと思っています。
どうすれば誰にも見られずにラブレターを伊藤さんに届けることができるでしょうか？

注: たとえ話を読む前に

まあこれがもし現実だとしたら、かなり特殊で不気味かもしれませんが、そこはたとえ話だということで、スルーしながら読んでやってください。

サチコさんが伊藤さんにラブレターを届けるまで

サチコさんは毎日電信柱の影から憧れの伊藤さんの姿を見ていました。
ある日、サチコさんはついに意を決し、電信柱の影から飛び出しました。

「あなたにラブレターを送りたいです！」

サチコさんは向こうから歩いてきた伊藤さんにラブレターの送信を申込みました。

「わ、わかりました・・・。」

伊藤さんは少しとまどいながらもそう返事し、サチコさんの住所を書き留めました。

数日後、伊藤さんはサチコさん宛に鉄の封筒を郵送しました。
鉄の封筒の中には西脇市長の署名が付いた印鑑証明書が入っています。
さらに、伊藤さんが特注して作った南京錠も一緒に入っています。
鉄の封筒は簡単に開けられないよう、西脇市共通の南京錠で施錠されています。

f:id:JunichiIto:20130525165005p:plain:w400

サチコさんのもとに、伊藤さんから送られた鉄の封筒が届きます。
サチコさんも西脇市民なので、西脇市共通の南京錠を開ける鍵を持っています。
サチコさんは封筒の南京錠を開け、封筒の中から印鑑証明書と伊藤さんの南京錠を取り出します。

f:id:JunichiIto:20130525165015p:plain

サチコさんは印鑑証明書をチェックします。
印鑑証明書にはちゃんと伊藤さんの氏名が載っていました。
また、印鑑証明書には信頼できる西脇市長の署名も入っていました。
これで封筒の送り主が近所に住む怪しい中年男性の「エスパー伊藤さん」ではなく、「自分が憧れているイケメン伊藤さん」であることが確認できました。

安心したサチコさんは、サチコ家に代々伝わる「宝箱作成マシーン」を使って、ラブレターを入れる宝箱と宝箱用の鍵2本を自作します。

f:id:JunichiIto:20130525165058p:plain:w400

サチコさんは伊藤さんにも宝箱の鍵を届ける必要がありますが、そのまま郵送すると途中で誰かに鍵を盗まれるかもしれません。
そこで、伊藤さんから届いた南京錠の出番です！
サチコさんは宝箱の鍵を鉄の封筒に入れ、伊藤さんの南京錠で施錠します。
これで安心して宝箱の鍵を伊藤さんに郵送できます。

f:id:JunichiIto:20130525165114p:plain:w400

伊藤さんのもとに、サチコさんから送られた鉄の封筒が届きます。
封筒は南京錠で施錠されていますが、この南京錠はもともと自分のものなので、南京錠を開けるための鍵は伊藤さんが持っています。
伊藤さんが南京錠を外し、鉄の封筒を開けるとそこには宝箱の鍵が入っていました。

f:id:JunichiIto:20130525165126p:plain:w400

これでようやくラブレターを送る準備が整いました。
サチコさんはラブレターを書き、宝箱に詰めて伊藤さんに郵送します。
もちろん宝箱には鍵をかけます。

f:id:JunichiIto:20130525165146p:plain:w300
f:id:JunichiIto:20130525165154p:plain:w300

伊藤さんのもとへサチコさんから宝箱が届きます。
伊藤さんは数日前にサチコさんから届いた宝箱用の鍵を使って宝箱を開けます。
中にはサチコさんの愛がたくさん詰まったラブレターがありました。

f:id:JunichiIto:20130525165206p:plain:w400

伊藤さんは返事を書き、それを先ほどの宝箱に入れてサチコさんに郵送します。

f:id:JunichiIto:20130525165218p:plain:w400

サチコさんのもとへ宝箱が帰ってきました。
サチコさんは宝箱の鍵を開け、憧れの伊藤さんからの返信を手に取りました。

f:id:JunichiIto:20130525165250p:plain:w400

そしてサチコさんは嬉々として返信を読みはじめました。

「ごめんなさい、実は妻子がいるんです。」

サチコさんは逆上し、宝箱の鍵を橋の上から投げ捨てました。
伊藤さんも「もうすべては終わったことだ」と自分に言い聞かせ、宝箱の鍵を燃えないゴミとして廃棄処分しました。

こうして誰も知らない伊藤さんとサチコさんの愛の物語は幕を静かに閉じたということです。

おしまい！

全体の流れ

なんかとても変なストーリーでしたが、上のたとえ話の流れをざっくりまとめるとこんな感じです。

f:id:JunichiIto:20130525222722p:plain
　

伊藤さんはサチコさんに自分の南京錠を郵送する。南京錠の鍵は自分が持っている。
サチコさんは宝箱の鍵を伊藤さんの南京錠で施錠して、伊藤さんに郵送する。
伊藤さんは南京錠を開けて、宝箱の鍵を取得する。
サチコさんはラブレターを宝箱に入れて、伊藤さんに郵送する。
伊藤さんは宝箱を開けて、ラブレターを読む。
伊藤さんは返信を宝箱に入れて、サチコさんに郵送する。
サチコさんは宝箱を開けて、返信を読む。

解説

結局のところ、サチコさんと伊藤さんが実現したいことは、誰からも見えないように宝箱に手紙を入れ、鍵をかけて郵送しあうことです。

しかし、宝箱の鍵はサチコさんと伊藤さんの双方が事前に手に入れておく必要があります。
もちろん、それ以外の人の手に渡ってはいけません。

そこで、伊藤さんは自分の南京錠をサチコさんに郵送し、サチコさんは宝箱の鍵をその南京錠で施錠して、伊藤さんに郵送します。
この南京錠の鍵を持っているのは伊藤さんだけなので、伊藤さんだけが宝箱の鍵を手に入れることができます。

ただし、サチコさんは間違っても宝箱の鍵やラブレターを近所の「エスパー伊藤さん」に渡してはいけません。
そこで、西脇市役所が間に入り、南京錠の送り主が間違いなく「イケメン伊藤さん」であることを証明するのです。

南京錠と宝箱

たとえ話の中では、大事な物を隠して送るために、2種類の方法が出てきます。
ひとつは南京錠で、もう一つは宝箱です。

南京錠の特徴は、施錠と解錠の方法が異なることです。
施錠は誰でもできますが、解錠は鍵を持っている人しかできません。

一方、宝箱は閉める時も開けるときも同じ鍵を使います。
なので、双方が同じ鍵を持っておく必要があります。

南京錠とそれを開ける鍵は、公開鍵と秘密鍵に当たります。
一方、宝箱の鍵は共通鍵(共通の秘密鍵)に当たります。

コンピュータの場合、毎回公開鍵方式でやりとりすると、暗号化と復号化の手間がかかります。
なので、安全に共通鍵を受け渡しできたら、それ以後は手間があまりかからない共通鍵方式でデータの暗号化と復号化を行ないます。

たとえ話と技術用語の対応関係

それではここから、上のたとえ話と実際の技術用語の対応関係を挙げていきます。

西脇市役所、西脇市長

SSL認証局(CA = Certificate Authority)

イケメン伊藤さん

Webサーバー、またはWebサーバーの管理者

サチコさん

ブラウザ、またはWeb利用者
現実には伊藤さんが応対すべきサチコさんは一人だけではなく、Web利用者の数だけ存在する

西脇市役所の南京錠と南京錠を開ける鍵

CAの秘密鍵と公開鍵
メジャーなCAの公開鍵はブラウザに予めインストールされている

伊藤さん特注の南京錠と南京錠を開ける鍵

サーバーの公開鍵と秘密鍵
サーバーの公開鍵と秘密鍵はサーバー管理者が作る
秘密鍵はサーバー管理者が厳重に保管する必要がある

伊藤さん特注の南京錠が添付された印鑑証明書

CAが発行したサーバー証明書
サーバー証明書にはCAのデジタル署名(=印鑑証明書)とサーバーの公開鍵(=伊藤さん特注の南京錠)が含まれている
サーバー証明書はCAの秘密鍵で暗号化されている
ブラウザはCAの公開鍵(=西脇市共通の鍵)を持っているので、サーバー証明書を復号化できる

サチコさんが作った宝箱の鍵

重要なデータを暗号化＆復号化するための共通鍵(秘密鍵)
共通鍵はブラウザ内で必要に応じて都度生成＆破棄される
共通鍵はブラウザとサーバー以外の第三者に渡してはならない

宝箱の鍵を鉄の封筒と伊藤さん特注の南京錠で施錠して、伊藤さんに郵送する

共通鍵をサーバーの公開鍵で暗号化してサーバーに送信することに当たる
サーバーはサーバーの秘密鍵を使って共通鍵を復号化する
これによりブラウザとサーバーの双方が同じ共通鍵を持つ

ラブレター

暗号化したい重要なデータ(フォームデータ等)

宝箱にラブレターを入れて送る

重要なデータを共通鍵で暗号化して、相手に送信することに当たる
データの受信者は共通鍵でデータを復号化する
共通鍵はブラウザとサーバーだけが持っているので、相互に暗号化したデータのやりとりが可能になる

宝箱の鍵を投げ捨てる / 廃棄処分する

共通鍵はセッション単位で生成、破棄されます。

第2部・SSLを利用するための準備

さて、読者のみなさんはここまですでにお腹いっぱいになってるかもしれませんが、あともう少しだけお付き合いください。

残っているのは「じゃあ、自分の作ったWebサービスをSSL化しようと思ったらどうするの？」という話です。

これは極端に単純化して言うなら、

CA(=市役所)にサーバー証明書(=印鑑証明書)を作ってもらい、サーバー証明書とサーバーの秘密鍵(=伊藤さん特注の南京錠)をWebサーバーに置けば良い。

ということになります。

しかし、これだけだとざっくり過ぎるので、もうちょっと詳しく見てみましょう。

署名要求(CSR)をCAに送る

サーバー証明書はSSL証明局(CA)が発行します。
なので、サーバー管理者はCAにサーバー証明書の発行を依頼します。
このときにサーバー管理者側で作成し、CAに送信するのが署名要求(CSR = Certificate Signing Request)です。

CSRにはサーバーの公開鍵データが含まれます。
また、CSR作成時には同時にサーバーの秘密鍵も生成されます。

CSRはCAに送信するものなので、CAにCSRを送信するということは同時にサーバーの公開鍵も一緒に送信することになります。
一方、サーバーの秘密鍵はCAには送らず、サーバー管理者が厳重に保管しておく必要があります。

CSRはターミナルのコマンドを叩いて作ることもできますし、オンラインのCSR作成ツールを使って作成することもできます。

CAは申請者を審査する

CSRを受け取ったCAは、CSRの内容に基づいて申請者を審査します。
審査の結果、申請者の正当性を確認できれば、CAはサーバー証明書を発行します。
サーバー証明書にはCAのデジタル署名(=西脇市長の署名)とサーバーの公開鍵(=伊藤さんの南京錠)が含まれます。

さあ、これでサーバーの秘密鍵とサーバー証明書が揃ったから準備OK！・・・ではなく、さらに「中間証明書」が必要になることがよくあります。
では、この中間証明書とは何なのでしょうか？

中間CAによる認証であれば、中間証明書もゲットすべし

自己の正当性を自分で証明できないCAは中間証明局(中間CA)と呼ばれ、上位のCAに正当性を証明してもらう必要があります。
そして、自分のサーバーの正当性が中間CAによって証明された場合は、サーバー証明書だけでなく、中間CAの中間証明書も用意する必要があるのです。

ちなみに、自己の正当性を自分で証明できるCAはルート証明局(ルートCA)と呼ばれます。
ルート証明局が発行した自分自身の証明書をルート証明書と呼びます。

SSLの仕組みの説明では、「ブラウザには予めメジャーなCAの公開鍵(=証明書)がインストールされている」と書きましたが、このときのCAはCAでも、基本的にルートCAのことを指しています。

中間証明書はCAごとに共通なので、サーバー証明書を発行した中間CAが発行している中間証明書をダウンロードして取得します。

必要なファイルをサーバーにアップロードすれば、準備OK！

中間証明書も取得できれば、今度こそ完了目前です。
サーバー証明書、中間証明書、サーバーの秘密鍵の3ファイルをWebサーバーにアップロードします。

利用しているサーバーやプラットホームによっては、さらにひと手間かかる場合もありますが、基本的な流れはこのようになります。

SSLを利用する場合の流れ

SSLを利用するための準備を図で表すとこんな感じになります。

f:id:JunichiIto:20130525232242p:plain
　

サーバー管理者はCSRを作成し、CAにCSRを送信する。
CSR作成時にできたサーバーの秘密鍵はサーバー管理者にて保持する。
CAはCSRの内容に基づいて、申請者を審査する。
問題がなければサーバー証明書を発行する。
サーバー管理者はCAの中間証明書をダウンロードする。
サーバー管理者はサーバー証明書、中間証明書、サーバーの秘密鍵の3点をサーバーにアップロードする。

参考: 各ファイルの中身

参考までに、上記ファイルの中身がどうなっているか紹介します。

CSR
よくある拡張子は"csr"。

-----BEGIN CERTIFICATE REQUEST-----
MIICuTCCAaECAQAwdDELMAkGA1UEBhMCSlAxDjAMBgNVBAgTBVRva3lvMRAwDgYD
...
xHqEx4P8dJFNXhnjUtcYRgu9T1YFYuMmldH/abU=
-----END CERTIFICATE REQUEST-----

　
サーバー証明書
よくある拡張子は"crt"や"cert"。

-----BEGIN CERTIFICATE-----
MIIFQzCCBCugAwIBAgIDDDgmMA0GCSqGSIb3DQEBBQUAMDwxCzAJBgNVBAYTAlVT
...
TxSNzzqCqg==
-----END CERTIFICATE-----

　
中間証明書
よくある拡張子は"pem"。

-----BEGIN CERTIFICATE-----
MIID1TCCAr2gAwIBAgIDAjbRMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT
...
LEL2TxyJeN4mTvVvk0wVaydWTQBUbHq3tw==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT
...
b8ravHNjkOR/ez4iyz0H7V84dJzjA1BOoa+Y7mHyhD8S
-----END CERTIFICATE-----

　
サーバーの秘密鍵
よくある拡張子は"key"。

-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAuVOVNicCbqvlklH7e+OwGv0PskyHmWlReJFmPu13ADxUHC3U
...
dRYkPm5dUZPpxbRh6W5eK9YM548I4B6/Q+xOM5ZX/vrDwD1admtW5Q==
-----END RSA PRIVATE KEY-----