サーバ証明書と中間証明書とルート証明書の関係について書いておく。
実際のhttpsのwebサイトでは、サーバ証明書は、サーバ証明書の発行者(中間認証局)の秘密鍵で署名される。中間認証局は自己署名証明書を発行する。この自己署名証明書の中に中間認証局の公開鍵が含まれる。その後、ルート認証局が中間認証局の公開鍵を含む中間証明書を署名することで、信頼できる証明書となる。つまり中間証明書は2つの署名がされている。ルート証明書は、ルート認証局の秘密鍵で署名されている。
中間証明書がルート証明書によって署名されている場合は、中間証明書の「Signature Algorithm」フィールドには、中間認証局とルート認証局の署名の両方が入っている。
Webサーバーからクライアントに提供される証明書チェーンは、サーバ証明書、中間証明書、ルート証明書の順に連鎖している形になっている。つまり、クライアントはサーバ証明書を受け取り、サーバ証明書が信頼できるかどうかを判断するために中間証明書を確認し、中間証明書が信頼できるかどうかを判断するためにルート証明書を確認することで、ルート認証局が信頼できるかどうかを確認する。
サーバ証明書の中間認証局が署名した署名は中間証明書の公開鍵で確認する。
中間証明書のルート認証局が署名した署名はルート証明書の公開鍵で確認する。
ルート証明書のルート認証局が署名した署名はルート証明書の公開鍵で確認する。
次のコマンドで証明書が認証局(CA)で署名された証明書であることを確認する。「openssl verify -CAfile」の使い方は次の通りである。
このコマンドは、サーバー証明書が認証局(CA)によって署名されているかどうかを確認する。
「CA bundle file」には、ルート証明書or証明書チェーン(ルート証明書+中間証明書+サーバー証明書)を指定する。「CA bundle file」には必ずルート証明書あるいはオレオレ証明書が含まれる必要がある。
「bundle file」という用語自体は、単に複数のファイルを1つにまとめたファイルのことを意味する。証明書の場合は証明書チェーンを意味する。
「server certificate file」には、サーバー証明書or中間証明書orルート証明書を指定する。
openssl verify -CAfile <CA bundle file> <server certificate file>
サーバー証明書、中間証明書、ルート証明書、証明書チェーン(ルート証明書+中間証明書+サーバー証明書)をhttpsのwebサイトからダウンロードしてきて、次のようにコマンドを実行すると証明書が認証局(CA)で署名されたことを確認できる。
サーバー証明書→中間証明書→ルート証明書
のように、最後はルート証明書で終わる。これが証明書チェーンである。
サーバー証明書→中間証明書(サーバー証明書は中間認証局が署名している。)
中間証明書→ルート証明書(中間証明書はルート認証局が署名している。)
ルート証明書→ルート証明書(ルート証明書はルート認証局が署名している自己署名証明書である。)
中間証明書は中間認証局の署名とルート認証局の署名の2つの署名がしてある。
しかし、中間証明書の検証にはルート証明書を指定したら「OK」となるから、中間証明書の自己署名は検証していないみたいだな。
これは証明書に署名が2つ以上あっても1つの署名が検証して正しければ「OK」ということかな。
openssl verify -CAfile 証明書チェーン サーバー証明書
openssl verify -CAfile ルート証明書 中間証明書
openssl verify -CAfile ルート証明書 ルート証明書
次のようにサーバー証明書→中間証明書を確認しようとした場合、中間証明書がルート認証局で署名されたことが確認できないため失敗する。
openssl verify -CAfile 中間証明書 サーバー証明書
下記の環境でopensslコマンドを実行した。linuxでも同じコマンドで動くと思うけど未確認である。
環境
Windows10
使用したGit Bashのバージョンは「git version 2.40.0.windows.1」である。