はじめに
例えばネットサーフィンを行う際、HTTPSを用いるとWebサーバのサーバ証明書の検証をWebサイト閲覧端末で行い、接続するサーバの正当性を確認して暗号化通信を行います。
この一連の流れを図示したものが以下となり
ポイントは以下の二つです。
- Webサーバの公開鍵を使って端末が暗号化し、Webサーバは秘密鍵で復号化する
- 端末はWebサーバの公開鍵が本当にWebサーバのものなのか検証を行う
本記事では二つ目のWebサーバの公開鍵の正しさを検証するための流れについて解説します。
証明書検証の登場人物
サーバ証明書の検証を説明するべく、登場人物は以下の３つとします。
原理は同じなので中間認証局は割愛します。興味がある方は署名の連鎖に関する別の記事を参考ください。
本題の説明のために以下の図を用意しました。ネットサーフィンをしている端末がクライアントでウェブサイトを提供しているのがWebサーバです。
図にあるサーバ証明書Aの中身ですが、
「情報」＋「署名」という２つの構造で構成されています。
情報
Webサイトのドメイン名やWebサーバAの公開鍵、証明書の有効期限など、その他諸々の情報が入っています。
署名
認証局が署名をします。
具体的な署名とは、上の情報群をハッシュにかけ、文字列にします。
ハッシュ化された文字列を認証局の秘密鍵で暗号化します。
この情報と署名の流れを簡略化すると以下の図となります。
Webサーバが提示した情報に認証局が署名を付け足し、
情報＋署名でサーバ証明書が構成されているイメージです。
ここでのミソは署名があるおかげで証明書の情報を改竄すれば検知できる点にあります。
クライアントが検証を行う
例えば、WebサーバA用の証明書のドメイン名を勝手に変更して別のサーバBで使おうとしたり、WebサーバAの公開鍵を勝手に自前の公開鍵にしてサーバ証明書を用いようとしても、同じ過程でハッシュ化すると端末はこの証明書が改竄されていることが分かってしまいます。
上の図に合わせて説明すると
- １段目：サーバ証明書を受け取る
- ２段目：サーバ証明書の情報部分と署名部分を分ける
- ３段目：情報部分をハッシュする
- ４段目：署名部分を認証局の公開鍵で複合する
ハッシュするアルゴリズムに関しては証明書に記載されており、認証局の公開鍵はルート証明書としてあらかじめクライアント側にインストールされています。
これが一致すれば、改竄されていないことが確認できます。
情報部分、または署名部分、どこか１文字でも変更があるとこれらは一致しないので証明書を信用できないと突きかえすことが可能、という流れです。
ここまでのチェックを証明書検証と呼び、ホスト名がこの証明書に記載されているドメイン名と一致しているか、という観点の検証を特にホスト名検証と呼びます。
終わりに
このあたりは意識せずともSSL通信の恩恵を享受することは可能ではありますが、エンジニアの方であればこのあたりの機構を抑えておくとよいと思い記事にしました。
以上、ご参考になれば幸いです。