httpsを使用すると、ブラウザはサーバーに要求し、サーバーは公開鍵とCA署名を含む証明書を返します。この時点でSSL質問：ROOT CAが署名を確認する方法
は、ブラウザは、指定された公開鍵が本当にサーバーに属しているかいないかどうかを確認するために、そのCAを聞いてきますか？
はどのようにこの検証は、ブラウザ上のルート証明書によって行われますか？例を与えるために
： 言うサーバXは、CA「ROOTCAのCA」から証明書を取得しました。ブラウザにはローカルに保存されたrootCAのコピーがあります。ブラウザがserverXにpingを発行し、公開鍵+署名で応答します。ルートCAは秘密鍵を使用して署名を復号化し、本当にserverXであることを確認します。
どのように動作するのですか？
サーバーには、プライベートキーと公開キーで構成される証明書があります。サーバーは秘密鍵を決して提供しませんが、誰もが公開鍵を取得する可能性があります。公開鍵は、証明書コンテナ形式に埋め込まれています。この形式には、サーバーのIPアドレスまたはドメイン名、このIPアドレス/ドメイン名の所有者、所有者の電子メールアドレスなどが含まれます。
すべてが信頼できる機関によって署名されています。信頼できる機関、すなわち認証局（CA）もまた、秘密/公開鍵のペアを有する。証明書を渡し、コンテナ内の情報が正しいことを確認し、秘密鍵で署名し、アクセスできるのは彼らだけです。
CAの公開鍵は、デフォルトではユーザシステムにインストールされていますが、よく知られているCAはすでにお気に入りのOSまたはブラウザのデフォルトインストールに含まれています。
ユーザーがサーバーに接続すると、サーバーは秘密キーを使用してデータに署名し、署名されたデータを公開キーと共にパックし、すべてをクライアントに送信します。
クライアントは現在何をすることができますか？まず、署名されたデータを検証するために送信したばかりの公開鍵を使用することができます。秘密鍵の所有者だけが、公開鍵が署名を検証できるような方法でデータに正しく署名することができるため、このデータに署名した人は誰でも、受信した公開鍵に秘密鍵を所有している。これまでのところうまくいきました。しかし、ハッカーがパケットを傍受し、署名されたデータを別の証明書を使用して署名したデータで置き換え、公開鍵を公開鍵で置き換えるのは何ですか？何もない。
署名されたデータが検証された後（または検証前に）、クライアントは受信した公開鍵が有効なCA署名を持っていることを確認します。既にインストールされている公開CA鍵を使用して、受信した公開鍵が既知のCAによって署名されていることを検証します。さもなければ、それは拒否されます（ハッカーは途中でそれを置き換えたかもしれません）。
最後に、公開鍵コンテナ内の情報をチェックします。 IPアドレスまたはドメイン名は、クライアントが現在話しているサーバのIPアドレスまたはドメイン名と実際に一致していますか？そうでなければ、何か怪しいです！
ハッカーが自分の鍵ペアを作成するだけで、ドメイン名またはIPアドレスを証明書に入れることを止めるのは何ですか？簡単に：彼がそれをするなら、彼の鍵に署名するCAはない。 CA署名を取得するには、実際にこのIPアドレスまたはドメイン名の所有者であることを証明する必要があります。ハッカーは、彼がそれを証明することはできません、彼は署名を取得しませんではありません。だからこれはうまくいきません。
さて、ハッカーは自分のドメインを登録し、そのドメインの証明書を作成し、CAによって署名されていますか？これは動作します、彼はそれがCAの署名を取得します、それは彼のドメイン、問題ありません。しかし、彼はあなたの接続をハッキングするときにこれを使うことはできません。彼がこの証明書を使用すると、ブラウザは署名された公開鍵がexample.netのドメインであることを直ちに認識しますが、現在同じドメインではなくexample.comと話しています。
お使いのブラウザではなく、それがローカルに保存されているルート本命のコピーを持って、確認するためにCAを求めていません。また、証明書が本当に有効であることを確認するために、標準の暗号化の手順を使用します。
これは、自己署名証明書が有効でない場合、CAが技術的に依頼しているにも関わらず、自己署名入りのCAをコンピュータにコピーしてから自分自身を信頼する認定。
CACert.orgでも有効な証明書がありますが、ブラウザにルート証明書がないため、ルートCAをダウンロードしてブラウザに追加するまで、証明書に警告が表示されます。
私には分かりません。 serverXがCA rootCAから証明書を取得したとします。ブラウザにはrootCA証明書がローカルに保存されています。したがって、ブラウザがserverXにpingすると、公開鍵+署名で応答します。ルートCAは秘密鍵を使用して署名を復号化し、それが本当にserverXであることを確認しますか？ – Sesh
いいえ、署名を確認するものは、自分の公開鍵を検証する私の秘密鍵で署名することができます。したがって、ローカルに格納されているルートCAは、実際にはCAのパブリック部分です。そのため、リモートサーバーが証明書を送信すると、署名は特定の署名を持ち、その署名は –
とCAの公開部分に対して数学的に計算され、CAの秘密部分が実際に証明書に署名したことを検証します。 –
サートは、RSAのような非対称暗号化を使用することに基づいています。従来、プライベートキーとパブリックキーと呼ばれる2つのキーがあります。何かを秘密鍵で暗号化できるのは、公開鍵を使ってのみ解読できます。
パスポートや運転免許証のようなものであると信じることができます。「これは私のものです。あなたはそれが私に与えられたので信頼できます。あなたが信頼する誰か（Verisignのような）によって。これは、「署名」で行われ、認証局の公開鍵を使用して計算することができます。データがCAが元来持っていたデータであれば、証明書を確認することができます。
証明書には、証明書の所有者に関する識別情報が含まれています。あなたがそれを受け取ったら、信頼できる当局から知っている鍵の組み合わせを使用して、受け取った証明書が有効であることを確認し、証明書を発行した人を信じることができると推測することができます。
サーバーの署名は取得するのが簡単でなければなりません。httpsリクエストを送信するだけです。 serverYがこのようにserverXのシグネチャを取得した場合、それはserverXを偽装することはできませんか？ – Sesh
いいえ、ブラウザに接続したときにユニークな開始（diffie hellmanキー交換）が使用されます.ServerYには、ブラウザが送信したものに基づいて公開鍵を計算するために使用される証明書の秘密鍵がない限り、serverX 。 –
Sesh、特定の条件の下でできることは、「インターポーザー」または「中間者」攻撃と呼ばれるものです。これにより、クライアントをサーバーに、サーバーをクライアントに、そしてすべてを傍受することができます。これに対して保護があります。 Googleの "人の真ん中"とSSLの詳細。 –
サーバー証明書は、CAの秘密キーで署名されています。ブラウザは、CAの公開鍵を使用して署名を検証します。ブラウザとCAの間に直接通信はありません。
重要な点は、パブリックCAキーでブラウザの船ということです。 Firefoxでは、ツール - >オプション - >詳細 - >暗号化 - > ViewCertificates-> Authoritiesを参照してください。したがって、ブラウザは、信頼できるすべてのCAを事前に知っています。
これを理解できない場合は、非対称暗号化とデジタル署名の基本を調べてください。
良い答え！しかし、別の関連する質問があります... 引用： "よく知られているCAは、お気に入りのOSまたはブラウザのデフォルトインストールに既に含まれています。" ブラウザが既定の既知のCAをどのように展開するのだろうか？それはWebサービスに対して自動チェックされますか？それとも、次のバージョンのブラウザリリースでのみ有効ですか？ – forestclown
CA証明書は、ブラウザまたはOSとともに出荷されます。 Firefox、Chrome、Operaには、独自のCA証明書コピーが含まれています。Internet ExplorerとSafariは、WindowsまたはOS XにインストールされたCA証明書を使用します。ブラウザは、独自のコピーとOSワイド証明書を使用できませんそれ）。ブラウザを更新したり、OSをアップデートしたり、手動でインストールしたりするだけで、新しいCA証明書を入手できます（ダウンロードしてからブラウザまたはOSに追加することも可能です）。 – Mecki
ブラウザがオンラインでチェックできるのは、CA証明書がまだ有効かどうかだけです。すべてのCAサービスは証明書失効サーバーを実行します。このサーバーでは、特定の証明書がまだ有効か無効になっているかどうかをブラウザが確認できます。これは、OCSPプロトコルを介して行われます。http://tinyurl.com/pcjk2証明書には、問い合わせるOCSPサーバーのアドレスが含まれています。 – Mecki