TLSハンドシェイクにおいてわからないことがあるので教えてください。

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384、鍵長 128bit、TLS1.2の暗号スイートを例とすると鍵交換はECDHEで認証はRSAと解釈できます

その場合、サーバー証明書に含まれる公開鍵Ⓐのペアの「秘密鍵Ⓐ」ってどこでつかわれますか？

サーバー証明書の検証にはCAの公開鍵Ⓑと秘密鍵Ⓑのペアを使うので、これだとサーバー証明書にふくまれる公開鍵Ⓐとペアの「秘密鍵Ⓐ」が使われる場面が無いのではないかと思いました。

仮に鍵交換がRSAだった場合はクライアントがサーバーの公開鍵Ⓐを使って共通鍵を暗号化しておくりサーバーは自身の「秘密鍵Ⓐ」で復号する流れができて「秘密鍵Ⓐ」を使う場面がでますが、鍵交換がECDHEだった場合は、サーバー証明書の公開鍵Ⓐとペアの「秘密鍵Ⓐ」はTLSハンドシェイクでは使用されないという解釈であっていますか？

最近TLSを学んで混乱しています

文字化けにつき再投稿
TLSハンドシェイクにおいてわからないことがあるので教えてください。

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384、鍵長 128bit、TLS1.2の暗号スイートを例とすると鍵交換はECDHEで認証はRSAと解釈できます

その場合、サーバー証明書に含まれる公開鍵Aのペアの「秘密鍵A」ってどこでつかわれますか？

サーバー証明書の検証にはCAの公開鍵Bと秘密鍵Bのペアを使うので、これだとサーバー証明書にふくまれる公開鍵Aとペアの「秘密鍵A」が使われる場面が無いのではないかと思いました。

仮に鍵交換がRSAだった場合はクライアントがサーバーの公開鍵Aを使って共通鍵を暗号化しておくりサーバーは自身の「秘密鍵A」で復号する流れができて「秘密鍵A」を使う場面がでますが、鍵交換がECDHEだった場合は、サーバー証明書の公開鍵Aとペアの「秘密鍵A」はTLSハンドシェイクでは使用されないという解釈であっていますか？

最近TLSを学んで混乱しています

TLSはとても複雑なプロトコルです。
利用される鍵交換方式によって、"Server Key Exchange"の内容は変化します。

TLSハンドシェイクで鍵交換アルゴリズムが"ECDHE_RSA"の場合、
"Server Key Exchange"メッセージで
・鍵交換には"ECDHE"（エフェメラルキー楕円曲線DH鍵交換)
・鍵交換に利用するDHパラメータの署名（認証）に"RSA"（デジタル署名）
が用いられます。
このデジタル署名を生成する際に、サーバに格納されている秘密鍵が利用されます。
クライアント側はこのデジタル署名を公開鍵（デジタル証明書）で検証し、
DHパラメータの真正性を確認します。

ポイントとして、鍵交換時のデジタル署名用に秘密鍵・公開鍵（デジタル証明書）が
利用されるということです。
暗号化に秘密鍵・公開鍵（デジタル証明書）が使われるわけではないです。

これでもかなり内容を端折っています。
実際のECDHEはかなり複雑な処理を行っています。
またこのフローはTLS1.2のものであり、TLS1.3では別になると思われます。

サーバー証明書はサーバーが正当であることを証明するものです。
サーバーの持ち主が秘密鍵で証明書に鍵をかけます。
多数のサーバーの利用者は、公開鍵で証明書にかけられた鍵を解錠できたら、その証明書は正当なものが鍵をかけたものであるということを認識できるってことじゃないでしょうか。

記載されている英語は鍵のハッシュ化とかの話なので、別で考えた方がすっきりするかもしれません。

pixさん
>・鍵交換に利用するDHパラメータの署名（認証）に"RSA"（デジタル署名）
が用いられます。
>このデジタル署名を生成する際に、サーバに格納されている秘密鍵が利用されます。

サーバー証明書の秘密鍵そこで使われていたのですね！すっきりしました。

ちなみにそうなると、TLSハンドシェイク中にクライアント認証フローがなかった場合はクライアント側から送られるDHパラメータには署名はつけられないという認識でよろしいでしょうか？クライアント証明書が送付されないということはクライアント証明書の中の公開鍵のペアの秘密鍵は存在しないので自己署名ができないですよね。
TLSは組み合わせによって違うっていうのもあるから本当複雑ですよね。
追加質問もお答えいただける範囲でよいのでお願いします。

せぼりゃさん
>サーバーの持ち主が秘密鍵で証明書に鍵をかけます。
>多数のサーバーの利用者は、公開鍵で証明書にかけられた鍵を解錠できたら、その証明書は正当なものが鍵をかけたものであるということを認識できるってことじゃないでしょうか。

サーバー証明書にされる署名はCAの秘密鍵で署名されるという認識ですが・・・
なにはともあれお答えいただきありがとうございます。

一般的な入門書や参考書に記載されているTLSのハンドシェイクの図は、
一番基本的なものです。
TLSは暗号スイートによって、ハンドシェイクシーケンスが大きく変化します。
特に鍵交換にDHを使った場合は大幅に変更されます。
そのため、一般的な入門書や参考書は内容を大幅に端折って書かれています。

>ちなみにそうなると、TLSハンドシェイク中にクライアント認証フローがなかった
>場合はクライアント側から送られるDHパラメータには署名はつけられないという
>認識でよろしいでしょうか？

はい。クライアントからのDHパラメータにはデジタル署名を付けられないというか
必須ではないというのが、正しいと思われます。

ECDHEで利用されるDHパラメータの実体は
・楕円曲線の種類
・使い捨ての公開鍵
です。
この使い捨ての効果鍵は、"certificate"メッセージで交換された
サーバ証明書（公開鍵）とは別のものです。
共通鍵を交換するだけに利用される、使い捨ての公開鍵になります。

"ServerKey Exchange"メッセージには
・DHパラメータ
・DHパラメータに対するデジタル署名
が生成されます。
しかし、その後の"ClientKey Exchange"メッセージには
・DHパラメータ
のみです。
これは前述のとおり、クライアント証明書は必須ではないため、
おのずとここでデジタル署名は必要ではないからです。

今回、この回答を考えるにあたり参考書やネットの情報を探しましたが、
ECDHEでの鍵交換のTLSパケットの情報はほとんどありませんでした。
このレベルでの詳細な挙動については、
・パケットキャプチャの出力
・RFC 5246 (TLS1.2)
といった実際の挙動から推測したものになります。

消極的な話になりますが、APレベルではここまで精密な暗号スイートの
挙動を理解しなくてもよいと思われます。
SCの設問でも、提示された暗号スイートが脆弱なものか否かという問題は
出題されたことはあります。しかし、DH鍵交換でのTLSシーケンスにまで
言及するような設問はなかったと記憶しています。

私も実業務で暗号スイートの選定を行うことがありますが、
挙動に関してはまだ十分に理解できていない段階です。

pixさん
＞消極的な話になりますが、APレベルではここまで精密な暗号スイートの
＞挙動を理解しなくてもよいと思われます。

私もネットや参考書をめちゃくちゃ調べての質問でしたので、あまりTLSハンドシェイクや暗号スイートに対して詳細に載っていないことは存じておりましたし、AP試験でのセキュリティやネットワークでも現在の出題傾向的に鍵関係すら出ないだろうなとは思っておりました。すみません。

ただなんというかTLSが楽しかったんです。難しいけど、証明書や署名、MACなどが実際具体的にどこで使われるのかが、体系的に理解できるなっておもったんです。
私は非ＩＴ職なのですごく新鮮でした。

今回二つの疑問が解決したので、それだけで大満足です。あまり深入りの沼にはまらないよう気を付けて勉強続けます。

またお世話になる時があるかとは思いますが、どうぞよろしくお願いします。