公開鍵証明書ってなんだっけ？

たまにはセキュリティの復習をば

アリスとボブが楽しそうに暗号文で通信しているよ！

HTTPSでは公開鍵を受け取ったあとに鍵交換を行い、最終的には共通鍵を使って暗号化しますが、いまは公開鍵のみに焦点を当てます。



ちょっとまって！その公開鍵、本当にAliceの？Bobは訝しんだ

Man in the middle攻撃

さっきの通信、実はMalloryがAliceのフリをしていました！いけませんね



さて困りました。『Aliceの公開鍵か、どうやって証明しよう』

証明書発行機関による、公開鍵証明書の発行

大変困ったので、マジで信用できる奴らに公開鍵を渡して、そいつらに証明してもらうことにしました。ついでにそいつらを証明書発行機関と呼ぶことにしました。マジで信用してます。信用することで成り立つ奴らです。

信用できる奴1人めは「登録局（RA）」くんです。Aliceは公開鍵をRAくんに送り、RAくんはAliceがどんなやつか、調査をします。調査をした結果、Aliceであることが確認できれば、証明書署名要求（CSR）を作ってくれます。

信用できる奴2人めは「認証局（CA）」くんです。RAから受け取ったCSRをもとに、認証局くんの署名付き公開鍵証明書を発行してくれます。発行した証明書はリポジトリに登録して管理されます。

ちなみに、このときのAliceのことを「主体者」と呼びます。



このようにして、Aliceは公開鍵を証明するためのアイテムを手に入れました。それじゃあ、Bobと暗号通信しよう！

公開鍵証明書の検証

とはいえBobは一度騙された身、CAくんの証明書も怪しく思えてしまいます。

ひとまず、証明書が失効されていないか確認します。X.509証明書であれば、Validityを確認しNot BeforeからNot Afterを過ぎていないかを確認します。Aliceの証明書は大丈夫でした。

次に、何かしらの理由（例えばCAくんが信用なくなったり、CAくんの秘密鍵が流出してしまったり）で証明書が使えなくなっていないかを確認します。CRLモデルで失効しているか確認するには、
CAからの失効リスト（CRL）をダウンロードして、証明書のシリアルナンバーが乗っていないかを確認します。OCSPモデルでは、OCSPレスポンダにシリアルナンバーを送り、失効していないか確認してもらいます。これもAliceの証明書は大丈夫でした。

それでは証明書の検証を行いましょう。これには、証明書・署名・CAくんの公開鍵を使用します。署名の検証は、証明書のハッシュ値と署名を公開鍵で復号した際の値が一致するかで行います。ここで問題になるのが、『公開鍵で復号』という言葉が正しいかどうかです。多分『公開鍵と署名に暗号化アルゴリズムに入力する』とか言ったほうが戦争が起きなくて済みそうです。ディジタル署名の話は本筋ではないのでこれで終わりにします。

ここまで無事に確認できれば、ほぼほぼ「この公開鍵がAliceのものである」と考えられます。Bobくんも安心してそうです。

ルート認証局と中間認証局

これまでの説明では、認証局を一つで説明しましたが、実際には認証局の公開鍵を証明する認証局という、認証局のネスト構造発生します。このとき、そのネストの途中に入っている認証局が中間認証局（中間CA）と呼ばれ、最後に来る認証局はルート認証局（ルートCA）と呼ばれます。

これらはどちらも証明書を発行する役割を持ちますが、証明書を検証するための公開鍵の検証方法が異なります。

中間CAの公開鍵は、その中間CAに対して公開鍵証明書を発行した別の中間CA、またはルートCAの公開鍵によって検証されます。対して、ルートCAの公開鍵を検証する方法はありません。ルートCAは社会的に『信頼できる』事によって、その公開鍵が本物であることを示します。最後は気合です。

多分これで公開鍵が本物か証明できるよ、やったね！