サーバ証明書とCSRの鍵長について
shutさん
(No.1)
サーバ証明書を発行するために、サーバ等ででCSRを生成すると思いますが、その時に指定する鍵帳(2048bit)はCAの署名アルゴリズムとは一切関係ないですよね。
例えばTLSを例にすると以下と考えています。
①CSR生成時の鍵長→クライアント、サーバ間で共通鍵を受け渡す時の秘密鍵、公開鍵の鍵長。
②CAの署名→CAで決められた署名アルゴリズム(SHAxxx RSA等)で署名する。①は関係ない。
お詳しい方がいらっしゃいましたらご確認をお願いできますでしょうか。
また、CSRは2048bitの鍵長で発行するケースがよくありますが、CAの署名アルゴリズムの鍵長は一般的にどれくらいなのでしょうか?(全く別物ですかね?)
例えばTLSを例にすると以下と考えています。
①CSR生成時の鍵長→クライアント、サーバ間で共通鍵を受け渡す時の秘密鍵、公開鍵の鍵長。
②CAの署名→CAで決められた署名アルゴリズム(SHAxxx RSA等)で署名する。①は関係ない。
お詳しい方がいらっしゃいましたらご確認をお願いできますでしょうか。
また、CSRは2048bitの鍵長で発行するケースがよくありますが、CAの署名アルゴリズムの鍵長は一般的にどれくらいなのでしょうか?(全く別物ですかね?)
2024.04.11 23:33
saitakaboさん
(No.2)
この投稿は投稿者により削除されました。(2024.04.13 01:08)
2024.04.13 01:08
saitakaboさん
(No.3)
①の鍵長は公開鍵のサイズです。
②はハッシュ値を求める時のアルゴリズムで、現在主流はSHA2の256ビットです。
CAはCSRに含まれる①の公開鍵を②のアルゴリズムでハッシュ値を求めCAの秘密鍵を使って署名します。公開鍵に署名がされるとデジタル証明書とか、サーバ証明書、クライアント証明書とか言わます。
サーバ証明書をTLSで利用する場合、サーバから提示されたサーバ証明書をクライアントで検証しますが、その検証処理の1つにハッシュ値の比較があります。
ハッシュ値はCAの秘密鍵で暗号化されているので、対となるCAの公開鍵でないと復号できません。主なCAの公開鍵は予めクライアントにインストールされています。
また、復号したハッシュ値と、署名アルゴリズムでクライアント自身で処理したハッシュ値と比較し同一なら、そのサーバ証明書は改ざんされていない事が証明されます。
(クライアントに入っているCAの公開鍵で復号できたという事も含め)
(CAの公開鍵はWindowsならWindowsUpdateの時に必要に応じて勝手に更新されます)
①②を合わせて証明書になっています。
②はハッシュ値を求める時のアルゴリズムで、現在主流はSHA2の256ビットです。
CAはCSRに含まれる①の公開鍵を②のアルゴリズムでハッシュ値を求めCAの秘密鍵を使って署名します。公開鍵に署名がされるとデジタル証明書とか、サーバ証明書、クライアント証明書とか言わます。
サーバ証明書をTLSで利用する場合、サーバから提示されたサーバ証明書をクライアントで検証しますが、その検証処理の1つにハッシュ値の比較があります。
ハッシュ値はCAの秘密鍵で暗号化されているので、対となるCAの公開鍵でないと復号できません。主なCAの公開鍵は予めクライアントにインストールされています。
また、復号したハッシュ値と、署名アルゴリズムでクライアント自身で処理したハッシュ値と比較し同一なら、そのサーバ証明書は改ざんされていない事が証明されます。
(クライアントに入っているCAの公開鍵で復号できたという事も含め)
(CAの公開鍵はWindowsならWindowsUpdateの時に必要に応じて勝手に更新されます)
①②を合わせて証明書になっています。
2024.04.13 01:09
納豆のたれさん
(No.4)
> ご確認をお願いできますでしょうか。
ブラウザで証明書チェーンを表示できるので、それを見れば確認できます。
chromeだと楕円曲線暗号の場合、鍵長が表示されないのでFirefoxで確認しました。
1)鍵長どころか、アルゴリズムが異なるパターン:みんな大好き Youtube
エンドエンティティ証明書
公開鍵アルゴリズム:楕円曲線公開鍵 (256)
署名アルゴリズム :SHA-256 with RSA 暗号化
中間証明書
公開鍵アルゴリズム:RSA 暗号化(2048)
署名アルゴリズム :SHA-256 with RSA 暗号化
ルート証明書
公開鍵アルゴリズム:RSA 暗号化(4096)
署名アルゴリズム :SHA-384 with RSA 暗号化
※中間証明書とルート証明書で鍵長が異なる
2)鍵長が異なるパターン:みんな大好き wikipedia
エンドエンティティ証明書
公開鍵アルゴリズム:楕円曲線公開鍵 (256)
署名アルゴリズム :ECDSA 署名(SHA-384)
中間証明書
公開鍵アルゴリズム:楕円曲線公開鍵 (384)
署名アルゴリズム :SHA-384 with RSA 暗号化
ルート証明書
公開鍵アルゴリズム:RSA 暗号化(2048)
署名アルゴリズム :SHA-1 with RSA 暗号化
3)統一されているパターン:みんな大好き amazon
エンドエンティティ証明書
公開鍵アルゴリズム:RSA 暗号化(2048)
署名アルゴリズム :SHA-256 with RSA 暗号化
中間証明書
公開鍵アルゴリズム:RSA 暗号化(2048)
署名アルゴリズム :SHA-256 with RSA 暗号化
ルート証明書
公開鍵アルゴリズム:RSA 暗号化(2048)
署名アルゴリズム :SHA-256 with RSA 暗号化
4)ルート証明書のビット長が大きいパターン:みんな大好き ネスペドットコム
エンドエンティティ証明書
公開鍵アルゴリズム:RSA 暗号化(2048)
署名アルゴリズム :SHA-256 with RSA 暗号化
中間証明書
公開鍵アルゴリズム:RSA 暗号化(2048)
署名アルゴリズム :SHA-256 with RSA 暗号化
ルート証明書
公開鍵アルゴリズム:RSA 暗号化(4096)
署名アルゴリズム :SHA-256 with RSA 暗号化
ルート証明書は自己署名なので、公開鍵と署名は、アルゴリズムもビット長も必然的に同じです。
2024.04.13 16:33
shutさん
(No.5)
saitakabo様、納豆のたれ様
ご回答ありがとうございます。
モヤモヤがすっきりしました。実際に自身の環境でも証明書を確認してみて納得がいきました!
ご回答ありがとうございます。
モヤモヤがすっきりしました。実際に自身の環境でも証明書を確認してみて納得がいきました!
2024.04.15 01:04
返信投稿用フォーム
スパム防止のためにスレッド作成日から30日経過したスレッドへの投稿はできません。