¿¿¿¿ ¿¿¿¿¿¿さん コメントありがとうございます。 動画がお役にたてて嬉しいです☺️ 全然コメントとは関係ありませんが お名前が？の反対向きというなので 疑問じゃない状態、つまり理解した状態という事なのかなぁ…と 勝手に思いふけりました（笑） 素敵なお名前ですね♪

もろこし23 さん お久しぶりのコメントですね。 ありがとうございます(^^) タイムリーな技術で 参考になっているようなのでうれしいです。 今後も動画更新していきますので 引き続きよろしくお願いいたします☆彡

Josui Kurodaさん コメントありがとうございます。 動画がお役にたててうれしいです(^^)

抹茶クッキーさん いつもコメントありがとうございます。 8:24 の部分について 動画でうまく説明できておらず申し訳ございません。 ＞署名前証明書は既にハッシュ化されているため、 デジタル署名をつけるために 署名前証明書をハッシュ化するだけで ユーザがデジタル証明書を入手した時は、 署名前証明書はハッシュ化されておりません。 ぜひ一度、実際のサーバ証明書をご覧いただくとイメージが湧くと思います faq.sakura.ad.jp/s/article/000001099 参考になれば幸いです。

きんくまさん こちらこそ、コメントありがとうございます！ 試験も近づいてきましたね😊 きんくまさんが良い結果を得られることを 願っております

抹茶クッキーさん いつもコメントありがとうございます！ ＞信頼性のない認証局に信頼性の強いEV証明書を作ってもらっても、 ＞それは信頼性の「ない」証明書になるのでしょうか？ はい、信頼性のない証明書として扱われます。 現実社会ですが、自称鑑定士の鑑定書のついた高級時計を買うかどうかで考えるとイメージしやすいかもしれません。 鑑定書はついてるけど、自称鑑定士なのでその鑑定書は信頼しませんよね？ いくらEV証明書でも、発行した認証局が信頼できなければ その証明書は信頼できません。 実際にはブラウザで”信頼できない証明書”という警告が出る事になると思います。

(初学者なので間違ってるかもしれませんが) サーバの公開鍵で暗号化するのは(※1)共通鍵で、 秘匿データを暗号化する際に使うのは(※1の)共通鍵だから、でしょうか？

ディジタル証明書の正当性を確かめるのは認証局の鍵ですが、実際に通信に利用する鍵は"通信相手のサーバーの共通鍵"で、認証局の公開鍵は使わないから不正解なのだと思います。 ディジタル証明書の中には、通信相手(今回でいうとサーバー)の公開鍵も含まれており、クライアントはサーバーの公開鍵を基に共通鍵を暗号化して送付します。受け取ったサーバーは自身の秘密鍵で共通鍵を複合し、以降共通鍵でクライアントとサーバーは暗号化通信を行います。

今回問われているのは認証局の公開鍵を利用して行うことです。 A社のWebサーバで利用しているデジタル証明書は、Webサーバの公開鍵に関して 認証局の秘密鍵で署名を受けることで作成されています。 認証局の公開鍵では対となる認証局の秘密鍵で暗号化された情報を復号可能ですし 認証局の秘密鍵で暗号化された情報を対となる公認証局の開鍵で復号可能です。 この例では認証局が認証局の秘密鍵で暗号化(署名)したA社の公開鍵に関するデータを クライアントが検証するために、認証局の公開鍵を使って署名を復号し 復号したデータとデジタル証明書からクライアント自身が計算するデータを比較し 一致すれば検証成功、正当な認証局で発行された正当なデジタル証明書であると確認できます。 上記の流れであるため不正解とはなりますが仮にエであった場合 どう不都合があるかといえば、認証局の公開鍵で暗号化された秘匿データは 対となる認証局の秘密鍵でしか復号できません(A社Webサーバは認証局の秘密鍵は入手できません) 実際通信したいのはA社のWebサーバであり、これではA社のWebサーバは秘匿データを受け取れません。 また仮にデジタル証明書の検証を行わずにWebサーバに対し秘匿データを送信する場合などは 偽サーバに対して通信を行ってしまった場合にそのまま送信してしまうことになります。 そのため問題のように認証局の公開鍵を使って、デジタル証明書を検証し 正規のwebサーバの公開鍵であることを確認した上で、webサーバの公開鍵を利用して鍵交換を行います。 また仕組みの問題として、デジタル証明書を受けとった段階では まだTLSハンドシェイクの最中であり、実際にwebサーバと通信するセッション鍵は生成されておらず HTTPのアプリケーションデータは送信されていません。 鍵交換が終わりChange Cipher Specメッセージを交換してからHTTPの通信が始まります。

xxs308giwさん コメントありがとうございます。 皆様も返信にてコメントありがとうございます。 私はこの問題は ”ディジタル証明書を検証してる” 事を理解しているか？ を問う問題だと思っています。 問題文にあるように サーバのディジタル証明書を入手した後には そのディジタル証明書の正当性を検証する必要があります。 暗号通信の話は”検証の後”です。 まずはディジタル証明書の検証を行い 正当性を確認できたら 暗号通信のための動きに移ります。 参考になりそうな WEBサイトがあったので共有させていただきます。 www.sc-siken.com/kakomon/23_aki/am2_3.html 参考になりますと幸いです😊

皆様コメント有難う御座います。 実際に暗号化するのがどの段階か、を理解できていませんでした。 丁寧にご教示頂きまして有難う御座いました！

ほんとだー！！ 田中電気さん貴重な情報ありがとうございます 個人的には このまま脱”ディジタル”して、”デジタル”にして欲しいです(^^)

Marcos Kasahara さん コメントありがとうございます。 同感です。 私も”デジタル”に統一して欲しいと思っています(*_*)

T Y さん コメントありがとうございます。 難しいですよね… ディジタル証明書は様々な要素が絡んでくるので 何かと理解が難しくなりがちです。 もし何が分からないのか分かったら 再度コメント頂けましたら 参考になりそうなサイトなどを紹介させていただきます！