!!!重要!!!
ここでの記載はあくまで、「サーバ証明書の真贋を検証する」ところまでをスコープとして記載している。
サーバ証明書が正常なものであることが分かった後のSSL/TLS通信の流れについては記載していない。
【認証局とサーバの処理について】
■前提: 認証局で作成しているファイルについて
認証局では、以下2ファイルを生成し、管理している。
①認証局で作成した秘密鍵
②認証局が自己署名したCA証明書(①で作成した秘密鍵を利用して作成)
オレオレ認証局であれば、上記①、②を自分自身で作成しなくてはいけない。
■1.秘密鍵と公開鍵の作成 ※サーバ側作業
公開鍵暗号方式の主流となっているのが、RSA2048bit。
■2.CSR作成 ※サーバ側作業
DN(ディスティングイッシュ・ネーム)とサーバの公開鍵をハッシュアルゴリズム(主流はSHA-1)でハッシュ化したもの。
※ハッシュアルゴリズムは、CSRをハッシュ化するのみで使用されるものであり、SHA-1でも問題ない。
※IEで証明書情報を見ると、「拇印アルゴリズム」として表記されている。
■3.サーバ証明書の作成方法について ※CA側作業
CSRを基に、サーバ証明書を作成。
■4.ハッシュ値の生成
上記3で生成したサーバ証明書とCA側の公開鍵をハッシュアルゴリズム(SHA-2が主流)でハッシュ化し、ハッシュ値を生成する。
※ここでのハッシュアルゴリズムは、サーバ証明書が正規のCAから発行されたものを証明するために使用されている。
※IEでは、「署名ハッシュアルゴリズム」として表示される。
※2019年現在でも話題になっている、「SHA1→SHA2移行」はココのこと!!!
■5.電子署名の発行
ハッシュ値をCA側の秘密鍵で暗号化する。(=電子署名と呼ぶ)
サーバ証明書と電子署名が合わさったものが、CSR提出者に送付される。
※ここで混乱するのは、サーバ証明書と電子署名は別物であること。クライアントがサーバに接続する際に、サーバ証明書と一緒に電子署名を受け取ることになる。
【クライアントとサーバの処理について】
■前提.クライアント側でサーバ証明書と電子署名を取得
クライアントからサーバにSSL通信を始める際、
クライアントはサーバからサーバ証明書と電子署名を一緒に受け取る。
■1.ハッシュ値を取り出す
ブラウザに元々組み込まれている認証局の公開鍵(=ルート証明書)を使用し電子署名を復号化すると、CA側で生成したハッシュ値が取得できる。
※組み込まれていない場合には手動で認証局からダウンロードし、ブラウザにインストールする必要がある。
■2.サーバ証明書とCAの公開鍵にて、ハッシュ値を生成
クライアント側では、サーバ証明書とブラウザに元々組み込まれている認証局の公開鍵(=ルート証明書)を使用して、
CA側で使用していたアルゴリズム(SHA2)でハッシュ値を生成する。
■3.上記1,2の結果を比較
上記1,2が同じハッシュ値であれば、サーバ証明書は正規のCAから発行されたものであるといえる。