証明書検証について
例えばネットサーフィンを行う際、HTTPSを用いるとWebサーバのサーバ証明書の検証をWebサイト閲覧端末で行い、接続するサーバの正当性を確認して暗号化通信を行います。
この一連の流れを図示したものが以下となります。
( ssl certificate - How does SSL really work? - Stack Overflow より図を抜粋 )
少し難しく見えますがポイントは単純で、
- Webサーバの公開鍵を使って端末が暗号化し、Webサーバは秘密鍵で復号化する
- 端末はWebサーバの公開鍵が本当にWebサーバのものなのか検証を行う
この二つです。
本記事では二つ目のWebサーバの公開鍵の正しさを検証するための流れについて解説します。
証明書検証の登場人物
サーバ証明書の検証を説明するべく、登場人物は以下の３つとします。
原理は同じなので中間認証局は割愛します。興味がある方は署名の連鎖に関する別の記事を参考ください。
この図にあるサーバ証明書Aの中身ですが、
「情報」＋「署名」という２つの構造で構成されています。
情報
Webサイトのドメイン名やWebサーバAの公開鍵、証明書の有効期限など、その他諸々の情報が入っています。
クライアントが検証を行う
例えば、WebサーバA用の証明書のドメイン名を勝手に変更して別のサーバBで使おうとしたり、WebサーバAの公開鍵を勝手に自前の公開鍵にしてサーバ証明書を用いようとしても、同じ過程でハッシュ化すると端末はこの証明書が改竄されていることが分かってしまいます。
上の図に合わせて説明すると
ハッシュするアルゴリズムに関しては証明書に記載されており、認証局の公開鍵はルート証明書としてあらかじめクライアント側にインストールされています。
これが一致すれば、改竄されていないことが確認できます。
情報部分、または署名部分、どこか１文字でも変更があるとこれらは一致しないので証明書を信用できないと突きかえすことが可能、という流れです。
用語説明ですが、
ここまでのチェックを証明書検証と言います。
そしてホスト名がこの証明書に記載されているドメイン名と一致しているか、という観点のホスト名検証を行い、接続先としての確認は完了です。