わかりやすく 証明書 SSL とは
前回は、署名を公開鍵で確かめました。鍵交換でも、公開鍵で閉めるときでも、いつも同じ前提がありました。手もとの公開鍵が本当にその人のものだ、という前提です。もし途中で誰かが自分の公開鍵をその人のもののように渡したら、閉めることも署名の確認も、まちがった相手と合わせることになります。初めて見るサイトの公開鍵を、私たちは何を根拠に信じればよいのでしょうか。
にせの公開鍵がまぎれこむ
これまでは、受け取った公開鍵をそのまま信じて使ってきました。当然その人のものだと思っていたわけです。ところが、自分と相手のあいだに誰かが入りこんでいると話が変わります。その誰かが本物の代わりに自分の公開鍵をこっそり渡すと、こちらは気づかないままそれで秘密を閉め、相手は自分の秘密鍵で開けて読んでしまいます。そのあと本物の公開鍵で閉め直して先へ渡せば、どちらも気づきません。
公開鍵という道具に欠陥はありません。揺らいでいるのは、それが誰のものかという一点だけです。鍵交換の回で残した宿題も、まさにこれでした。
送られる公開鍵を選んで押してみましょう。本物がそのまま届けば安全で、途中でにせ物にすりかえられると、秘密がまちがった手の中で開くことがわかります。
二つを並べると、違いははっきりします。本物が届けば何も起きませんが、にせ物が届いても、こちらの画面には公開鍵が一つ届いたとしか見えません。公開鍵はただの長い数で、名札はついていないので、それだけを見ても持ち主は見分けられません。
だから必要なのは、この公開鍵が本当にその人のものだと、信頼できる形で保証してくれる誰かです。その保証を引き受ける存在が、次に出てきます。
信頼された機関が保証する
ここで、みんなが信頼すると決めた機関が登場します。認証局、略してCAと呼ばれるところです。サイトは自分の公開鍵とドメイン名をCAに出し、CAは申請者が本当にそのドメインを管理しているかを確かめます。
確認が終わると、CAは公開鍵とドメイン名、発行者、有効期間を一つの文書にまとめ、自分の秘密鍵で署名します。前回の、偽造できないあの署名です。こうしてCAの署名がついた文書が証明書です。公開鍵に、信頼できる身分証がついたようなものです。
発行の段階を順に押してみましょう。サイトが公開鍵を出し、CAが確かめてから署名し、一枚の証明書にまとめます。
これで公開鍵はひとりで漂ってはいません。CAの署名が後ろから支えています。この署名はCAの秘密鍵でしか作れないので、誰にもまねできません。証明書を受け取った人はCAの公開鍵で署名を確かめ、合っていれば、そこに書かれた公開鍵が書かれたドメインのものだと信じられます。
証明書には有効期間もあり、期限の切れた証明書はもう保証として扱われません。ところが、まだ一つ問いが残ります。そのCAの公開鍵は、何を根拠に信じるのでしょうか。
ブラウザの信頼リスト、PKI
CAを信じる根拠は、思ったより単純です。OSやブラウザには、あらかじめ審査されたルートCAの証明書の一覧が最初から入っています。この一覧が信頼の出発点です。
ただし、ルートCAがすべてのサイトに直接署名するわけではありません。ルートCAの秘密鍵はふつうネットワークから切り離して厳重に保管され、日々の発行はルートが保証した中間CAが受け持ちます。そこでブラウザはサイトの証明書から出発し、署名したCAを一段ずつさかのぼって、信頼リストのルートに届いたところで検証を終えます。保証が保証へとつながるこの仕組み全体を、公開鍵基盤、略してPKIと呼びます。
鎖を一段ずつたどって上ってみましょう。サイトの証明書から出発し、中間CAを通って信頼リストのルートCAに届くと、検証が終わります。
鎖の先で、ブラウザが前から信じていたルートCAに出会いました。ルート証明書は自分で自分に署名したものなので、その信頼はリストに入っているという事実から来ています。そこまで鎖が切れずにつながれば、いちばん下のサイトの公開鍵まで信じられるようになります。
そのサイトを直接知らなくても、自分が信じるルートが中間CAを保証し、中間CAがサイトを保証したので信じるのです。では、実際に証明書が届いたとき、通過と警告は何で分かれるのでしょうか。
本物の証明書は通過、にせ物は警告
ブラウザは証明書を受け取ると、いくつかのことを順に確かめます。鎖が信頼リストのルートまでつながっているか、鎖の上の署名がすべて正しいか、証明書に書かれたドメインがいま接続しているアドレスと同じか、有効期間が切れていないかです。
すべて合えば通過し、アドレスバーに鍵のマークが出ます。一つでも合わなければ、ブラウザは大きな警告画面を出して接続を止めます。にせの公開鍵をふるい落とす門番が、この検証です。
二つの証明書を一つずつ検証してみましょう。信頼リストに届く本物は通過し、信頼できないところが署名したにせ物は警告が出ます。
本物は静かに通過し、にせ物はすぐ警告で止められました。ウェブでこのような警告画面に出会ったら、そのまま進んではいけないという意味です。そのサイトの公開鍵が、信頼できる形で保証されていないという知らせだからです。
また、サイトの秘密鍵がもれると、証明書がまだ有効でも危険になります。そのためCAはそうした証明書を失効させることができ、失効の情報を確かめる仕組みもあります。では、証明書が何を守るのかをまとめましょう。
まとめ
まとめるとこうなります。公開鍵を安全に使うには、それが本当にその人やそのサイトのものだと信じられなければなりません。途中でにせの公開鍵を渡す攻撃があるからです。そこで信頼された機関であるCAが確認したうえで、公開鍵とドメイン名、有効期間を一つの文書にして署名します。この文書が証明書です。
ブラウザはルートCAの一覧をあらかじめ持っていて、証明書の署名を鎖のようにさかのぼり、その一覧に届くかを確かめます。こうしてつながった信頼の網全体がPKIです。
四つの要点を順に押してふり返りましょう。にせの公開鍵の危険、CAの署名と保証、ルートまでつながる鎖、通過と警告の順です。
これで、初めて見る公開鍵を何を根拠に信じるのかがわかりました。ひとりで漂う公開鍵は誰のものかわかりませんが、CAの保証がついた証明書は信頼できます。毎日見るアドレスバーの鍵マークの後ろに、まさにこの証明書と信頼の鎖があります。
閉める、署名する、身元を保証するという部品が、これですべてそろいました。次の回では、サイトに接続する瞬間、これらがHTTPSの中でどう一緒に動くのかを見ます。