デジタル証明書とCAが本当に安全である方法を理解しようとする
デジタル証明書と認証局（信頼できるサードパーティ）がHTTPS接続中の中間者攻撃を防ぐのに役立つことを理解しています。しかし、私はいくつかの詳細について混乱しています。
「bob.com」にマップされたサーバーを持つクライアントAliceとBobがあるとします。
Bob（bob.com）がCA（veriSignとしましょう）に新しい証明書の作成を要求し、その証明書に公開鍵を送信するように送信すると、ハッカーによる要求の傍受を阻止し、公開鍵を次のように切り替えます。 CAに偽の証明書を作成させ、この偽の証明書をボブに返す。返された証明書の公開鍵が、要求でCAに最初に送信したものと一致することをボブが実際に確認する唯一の保護はここですか？そして、私はCAに、彼が受け取ったものは彼が送信したものと一致しないため、CAが誤った記録を保持しないことを通知しているのでしょうか。
BobがveriSignから取得した新しく作成された証明書が正当であると仮定して、アリスがHTTPSプロトコルを介して「bob.com」にリクエストを送信するとします。ハッカーがアリスへの途中でボブの新しい証明書を傍受し、新しい証明書を作成し、独自の秘密鍵（以前にverisignによって署名されていた）で署名し、その後、アリスのveriSignへのリクエストを傍受したときに、デュアルチャネルMITM攻撃を妨げているもの彼女はveriSignの公開鍵を要求し、それを悪意のある秘密鍵に一致する公開鍵で再び切り替えます。アリスは偽の証明書の整合性をチェックしようとすると、チェックアウトします。なぜなら、彼女は、veriSignの公開キーで署名をチェックしていると思っているにもかかわらず、本当に悪意のある公開キーを使用しているからです。
返された証明書の公開鍵が、要求でCAに最初に送信したものと一致することをボブが実際に確認する唯一の保護はここですか？
CAが証明書の作成に使用する前に公開鍵が切り替えられた場合、BobのWebサイトはまったく機能しません。安全に保管していた秘密鍵は、元の公開鍵でのみ機能します。攻撃者がすべての接続をMITMして、この事実が明らかになるのを防ぐことはできません。
は、アリスがveriSignの公開鍵を要求すると、veriSignへの要求をインターセプトし、悪意のある秘密鍵に一致する公開鍵を使用して再度それを切り替えます。
アリスはベリサインに手を差し伸べません。アリスは、自分のブラウザーまたはコンピューターの信頼された証明書ストアにあるCA証明書のコピーのみを信頼します。Verisignはたまたまその1つです。
信頼できる証明書ストアは、インストール時に（OS、またはFirefoxの場合はアプリケーションの）インストール時に入力され、必要に応じて通常のOSまたはアプリケーションの更新を介して更新されます。長命。
良い質問。最も信頼できるCAの証明書は通常、ソフトウェアインストールパッケージに含まれています。ブラウザインストーラ、OSインストーラ、またはスマートフォンなどのデバイスにプリインストールされています。そのため、証明書が本当に指定されたCAからのものであるかどうかがブラウザー（または他のアプリケーション）に通知されます。
あなたは本質的に、信頼できるCAを介して第三者が証明書を発行することを妨げているものを尋ねています。
コスト-CAは証明書の発行に課金します。この方法で数千を発行するのは法外な費用です。
ドメインの検証-信頼できるCAは、ドメインの所有権を正しく検証するために信頼されているため、信頼されているだけです。一部のCAは100％失敗し、信頼できるステータスを失っています。検証の1つの方法は、ドメインのレジストラにある技術担当者への電子メールです。ここには既知の弱点があります https://en.m.wikipedia.org/wiki/Certificate_authority#Validation_weaknesses