SSL通信で中間CA証明書の検証はどうやってるのか


はじめに

SSL/TLS について調べていたところ、中間 CA 証明書の検証で「OCSP」という単語が出てきたので、現時点でわかったことをまとめる。

SSL/TLS 通信の仕組み

そもそもの SSL/TLS 通信の仕組みは以下。(https://ssl.sakura.ad.jp/column/ssl/ より引用)

  1. ブラウザ:SSL 通信をリクエストする
  2. サーバー:SSL 証明書を送付する
  3. ブラウザ:電子署名の検証により「SSL 証明書に記載されたドメイン」と「通信先のドメイン」が同じであることを確認する
  4. ブラウザ/サーバー:SSL 通信を行うために共通鍵を交換する


https://ssl.sakura.ad.jp/column/ssl/ より引用)

2, 3 の部分で使われるサーバーの証明書は通常、ルート CA が発行するのではなく、中間 CA が発行する。


https://www.cybertrust.co.jp/sureserver/support/faq/442g976c4sgy.html より引用)

サーバーの証明書は中間 CA の秘密鍵によって署名され、中間 CA 証明書によって署名の検証ができる。
また、中間 CA 証明書はルート CA の秘密鍵によって署名され、ルート CA 証明書によって署名の検証ができる。

ブラウザでは、SSL 通信を始める際にサーバーからの受け取った証明書を検証し、正当であるかを判断する。
上記にある通り、サーバーの証明書を検証するためには中間 CA 証明書を使う必要がある。そこで、中間 CA 証明書が正当なものなのかを確かめる必要がある。検証するにはルート CA 証明書が必要である。
PC などのデバイスにはルート CA 証明書が出荷時から入っており、ブラウザはそのルート CA 証明書を使い検証をすることができる。

このようにルート CA 証明書で中間 CA 証明書を検証し、検証された中間 CA 証明書でサーバーの証明書を検証する仕組みとなっている。

証明書が失効した場合はどうするのか?

では、もしルート CA 証明書や中間 CA 証明書がなんらかの原因(秘密鍵が流出したなど)で失効した場合はどうするのか?

ルート証明書の場合は、PC に出荷時から入っているため、新しい証明書に切り替えるのは簡単ではない。調べたところ、Windows Update のような更新で証明書の更新が行われるらしい。

では、中間 CA 証明書の場合はどうするのか?

証明書が失効したからといって、ルート CA 証明書での検証が失敗するわけではない。
そこで、出てくるのがOCSP サーバーである。

OCSP とは

OCSP(Online Certificate Status Protocol)とは、単一の証明書のステータスについて確認するための http プロトコルです。

https://www.digicert.co.jp/welcome/pdf/wp_ssl_handshake.pdf より引用)

中間 CA 証明書の公開鍵ハッシュ値などを OCSP サーバーに送り、証明書のステータス(good, revoked, unknown)を返してくれるサーバーのこと。


https://www.digicert.co.jp/welcome/pdf/wp_ssl_handshake.pdf より引用)

SSL 通信を開始する際に OCSP サーバーに問い合わせ、有効であることを確認してから SSL 通信を開始することができる。

また、OCSP サーバーのレスポンスが改ざんされていないことを保証するために、OCSP サーバーからのレスポンスは署名されている。(この署名はどうやって検証しているのだろう?)

さいごに

中間 CA 証明書の検証についてどうやっているのかは大方イメージがついた。
OCSP サーバーからのレスポンスの署名検証がどのようにやっているのかは気になる。

また、CRL や OCSP ステープリングについてももう少し調査をしてみようと思う。

Ref