トップ > Tips > 【初心者向け】サーバ証明書の検証の流れについてまとめてみた

【初心者向け】サーバ証明書の検証の流れについてまとめてみた

Tips
記事タイトルとURLをコピーする

はじめに

smtps や ldaps などの SSL/TLS 通信をするときに、サーバ証明書の検証がよくわからず、検証しない設定にしてしまう方もいらっしゃるのではないかなと思います。

同じような設定に戸惑いたくなかったので、サーバ証明書の検証の流れについて整理してみました。

最後にパターンごとの具体例も載せているので、よければみてください！

記事目安...15分

サーバ証明書の検証とは?

接続先サーバから受け取ったサーバ証明書自体の 正当性を証明する ために、接続元クライアントがおこなう作業です。 悪意の第3者が、サーバ証明書に改ざんを加えてないかを確認します。

CA 証明書とサーバ証明書の検証方法は同じと考えていただいて構いません。

検証の動作については大きく2段階に分かれます。

  1. サーバ証明書に記載された公開鍵の検証
  2. サーバ証明書の検証

サーバ証明書に記載された公開鍵の検証

証明書に記載された公開鍵の情報が、改ざんされていないか確認を行う方法について説明します。

検証する証明書が、 ルート証明書か否か で、動作が変わります。

ルート証明書以外の場合(=サーバ証明書, 中間証明書の場合)

証明書チェーン(*1)より、公開鍵を認証しているさらに上位の 認証局(以下CA) の CA 証明書(=中間証明書)を確認します。

ルート証明書に行きつくまで、上記動作は繰り返されます。

上位の CA 証明書の検証に成功すれば、上位 CA に認証された公開鍵情報は正しいです。

*1. 証明書チェーンとは
サーバ証明書は、その認証の仕組みか複数の証明書が連なっています。この仕組みを 証明書チェーン と呼びます。

〇イメージ図

f:id:swx-sugaya:20201218155652p:plain

ルート証明書の場合

ルート証明書に書かれた公開鍵は、 最上位 CA の公開鍵であるため、ほかに認証をおこなう CA が存在しません 。

そのためルート証明書の検証を行う場合は、 接続元クライアントに インストールされている CA証明書群の公開鍵 と比較を行います。
(↑ソフトウェアの設定ファイルで、CA証明書を指定するのもこれが理由です。)

ルート証明書が正しいことがわかると、 接続元クライアントにインストールされた CA証明書の公開鍵と一致しない場合は、検証に失敗します。

有名な CA の CA証明書は、あらかじめ製造元や管理者によりインストールされているケースが多いそうです。

サーバ証明書の検証

続いて、サーバ証明書の内容に関する検証を説明します。

証明書の内容を検証するときは、大きく3つのステップに分かれます。

  1. 証明書に記載された電子署名を、公開鍵で復号し、ハッシュ値を取り出します。復号できない場合は、電子署名に改ざんがあると考えられるため検証に失敗します。
  2. 証明書に記載された電子署名以外の情報をハッシュ化します。
  3. Step1 と Step2 で取得したハッシュ値を見比べて、一致すれば証明書の検証に成功します。一致しない場合、証明書に記載された内容に改ざんがあると考えられるので検証に失敗します。

検証の具体例

上記の流れを抑えたうえで、いくつかサーバ証明書検証の具体例を追っていきます。

パターン1: 第三者 ルート CA に認証されている場合

そもそも第三者 CA がどうやってサーバ証明書を認証するのかわからない方は、こちらのブログを見ていただけると助かります。

f:id:swx-sugaya:20201218165552p:plain

  1. client software が、 server software に接続します。
  2. server software が、設定ファイルで指定された サーバ証明書 ( hogehoge.crt ) を、client software に送ります
  3. client software が、 サーバ証明書 ( hogehoge.crt ) の公開鍵検証を開始します
  4. client software が、 サーバ証明書 ( hogehoge.crt ) に紐づいた CA証明書( root_ca.crt ) の公開鍵検証を開始します。
    この CA証明書( root_ca.crt )は、ルート証明書なので、保存された CA証明書ファイルの公開鍵と一致しているか検証します。
  5. step4 の検証が正しければ、CA証明書( root_ca.crt ) の検証をします。
    改ざんがなければ、サーバ証明書( hogehoge.crt )の公開鍵が正しいことがわかります。
  6. step5 が問題なければ、サーバ証明書( hogehoge.crt ) の検証をします。
    改ざんがなければ、サーバ証明書 ( hogehoge.crt )の内容が正しいことがわかります。
  7. step6 が問題なければ、接続先サーバが正しいか、検証を行います
  8. step7 が問題なければ、client software が、SSL/TLS 通信を開始します。

パターン2: 第三者 CA に認証されている場合

f:id:swx-sugaya:20201218165606p:plain

  1. client software が、 server software に接続します。
  2. server software が、設定ファイルで指定された サーバ証明書 ( hogehoge.crt ) を、client software に送ります
  3. client software が、 サーバ証明書 ( hogehoge.crt ) の公開鍵検証を開始します
  4. client software が、 サーバ証明書 ( hogehoge.crt ) に紐づいた CA証明書( intermediate_ca.crt ) の公開鍵検証を開始します。
  5. client software が、 CA証明書 ( intermediate_ca.crt ) に紐づいた CA証明書( root_ca.crt ) の公開鍵検証を開始します。
    この CA証明書( root_ca.crt )は、ルート証明書なので、保存された CA証明書ファイルの公開鍵と一致しているか検証します。
  6. step5 の検証が正しければ、CA証明書( root_ca.crt ) の検証をします。
    改ざんがなければ、CA証明書( intermediate_ca.crt )の公開鍵が正しいことがわかります。
  7. step6 が問題なければ、CA証明書( intermediate_ca.crt ) の検証をします。
    改ざんがなければ、サーバ証明書( hogehoge.crt )の公開鍵が正しいことがわかります。
  8. step7 が問題なければ、サーバ証明書( hogehoge.crt ) の検証をします。
    改ざんがなければ、サーバ証明書 ( hogehoge.crt )の内容が正しいことがわかります。
  9. step8 が問題なければ、接続先サーバが正しいか、検証を行います
  10. step9 が問題なければ、client software が、SSL/TLS 通信を開始します。

パターン3: 自己証明書の場合

そもそも自己証明書がどうやって認証されるのかわからない方は、こちらのブログを見ていただけると助かります。

f:id:swx-sugaya:20201218165615p:plain

  1. client software が、 server software に接続します。
  2. server software が、設定ファイルで指定された サーバ証明書 ( hogehoge.crt ) を、client software に送ります
  3. client software が、 サーバ証明書 ( hogehoge.crt ) の公開鍵検証を開始します。
    この サーバ証明書( hogehoge.crt )は、ルート証明書なので、保存された サーバ証明書ファイルの公開鍵と一致しているか検証します。
  4. step3 が問題なければ、サーバ証明書( hogehoge.crt ) の検証をします。
    改ざんがなければ、サーバ証明書 ( hogehoge.crt )の内容が正しいことがわかります。
  5. step4 が問題なければ、接続先サーバが正しいか、検証を行います
  6. step5 が問題なければ、client software が、SSL/TLS 通信を開始します。

まとめ

ということで、サーバ証明書の検証の流れについてまとめました。

ポイントは以下です!

  • 個々の証明書の検証は、①公開鍵の検証, ②証明書の検証で、2段階に分かれている
  • ルート証明書は、事前に接続元で保持している必要がある

この内容を理解すれば、SSL/TLS 通信を好きになれるのではないかなと思ってます！

ご覧いただきありがとうございました！

菅谷 歩 (記事一覧)