web-dev-qa-db-ja.com

ルートCAはどのように署名を検証しますか?

Httpsを使用する場合、ブラウザはサーバーにリクエストを送信し、サーバーは公開鍵とCA署名を含む証明書を返します。

この時点で、ブラウザはCAに、指定された公開鍵が本当にサーバーに属しているかどうかを確認するように要求しますか?

この検証は、ブラウザのルート証明書によってどのように行われますか?

例を挙げると、serverXがCA「rootCA」から証明書を取得したとします。ブラウザには、rootCAのコピーがローカルに保存されています。ブラウザがserverXにpingを実行し、公開鍵+署名で応答したとき。これで、ルートCAはその秘密鍵を使用して署名を復号化し、それが本当にserverXであることを確認しますか?

それはどのように機能しますか?

31
Sesh

サーバーは、秘密鍵と公開鍵で構成される鍵ペアを作成します。もちろん、サーバーが秘密鍵を配布することはありませんが、誰でも公開鍵のコピーを入手できます。公開鍵は、証明書コンテナ形式(X.509)に埋め込まれています。このコンテナは、ラップされたキーに関連するメタ情報で構成されています。サーバーのIPアドレスまたはドメイン名、そのサーバーの所有者、電子メールの連絡先アドレス、キーが作成された日時、キーの有効期間、使用目的、およびその他の多くの可能な値。

コンテナ全体は、信頼できる認証局(= CA)によって署名されています。 CAには、秘密鍵と公開鍵のペアもあります。あなたは彼らにあなたの証明書を与え、彼らはコンテナ内の情報が正しいことを確認し(例えば、連絡先情報が正しいか、その証明書は本当にそのサーバーに属しているか)、最後に彼らの秘密鍵でそれに署名します。 CAの公開鍵をユーザーシステムにインストールする必要があります。最もよく知られているCA証明書は、お気に入りのOSまたはブラウザのデフォルトのインストールにすでに含まれています。

ユーザーがサーバーに接続すると、サーバーは秘密鍵を使用してランダムデータに署名し、署名されたデータを証明書(=公開鍵+メタ情報)と一緒にパックして、すべてをクライアントに送信します。クライアントはその情報で何ができますか?

まず、送信したばかりの証明書内の公開鍵を使用して、署名されたデータを検証できます。公開鍵が署名を正しく検証できるように、秘密鍵の所有者だけがデータに正しく署名できるため、このデータに署名した人は誰でも、この人が秘密鍵を所有していることがわかります。公開鍵を受け取りました。

しかし、ハッカーがパケットを傍受して、署名されたデータを別の証明書を使用して自分で署名したデータに置き換え、証明書を自分の証明書に置き換えるのを防ぐにはどうすればよいでしょうか。答えは単に何もありません。

そのため、署名されたデータが検証された後(または検証される前)に、クライアントは受信した証明書に有効なCA署名があることを確認します。すでにインストールされている公開CAキーを使用して、受信した公開キーが既知の信頼できるCAによって署名されていることを確認します。署名されていない証明書は、デフォルトでは信頼されていません。ユーザーは、ブラウザでその証明書を明示的に信頼する必要があります。

最後に、証明書自体の情報をチェックします。 IPアドレスまたはドメイン名は、クライアントが現在通信しているサーバーのIPアドレスまたはドメイン名と本当に一致していますか?そうでなければ、何かが怪しいです!

人々は疑問に思うかもしれません:ハッカーが自分のキーペアを作成し、ドメイン名またはIPアドレスを証明書に入れて、それをCAに署名させるのを妨げるものは何ですか?簡単な答え:彼がそうする場合、CAは彼の証明書に署名しません。 CA署名を取得するには、自分が本当にこのIPアドレスまたはドメイン名の所有者であることを証明する必要があります。ハッカーは所有者ではないため、それを証明できず、署名を取得できません。

しかし、ハッカーが自分のドメインを登録し、そのための証明書を作成し、それをCAが署名した場合はどうなるでしょうか。これは機能します。彼はCAに署名します。結局、それは彼のドメインです。ただし、彼はあなたの接続をハッキングするためにそれを使用することはできません。彼がこの証明書を使用すると、ブラウザは署名された公開鍵がドメインexample.net用であることをすぐに認識しますが、現在、同じドメインではなくexample.comと通信しているため、何かが再び間違っています。

72
Mecki

サーバー証明書は、CAの秘密鍵で署名されています。ブラウザはCAの公開鍵を使用して署名を検証します。ブラウザとCAの間には直接の通信はありません。

重要な点は、ブラウザには公開CAキーが付属していることです。したがって、ブラウザは、信頼できるすべてのCAを事前に認識しています。

これがわからない場合は、非対称暗号化とデジタル署名の基本を調べてください。

9
user34005

証明書は、RSAのような非対称暗号化の使用に基づいています。従来は秘密鍵と公開鍵と呼ばれる2つの鍵があります。 encrypt秘密鍵を使用して何かを復号化するには、公開鍵を使用する必要があります。 (そして、実際には、その逆です。)

証明書はパスポートや運転免許証のようなものと考えることができます。これは、「これが私です。信頼できる人(Verisignなど)から渡されたので、信頼できます」という資格情報です。これは、認証局の公開鍵を使用して計算できる「署名」を使用して行われます。データがCAが最初に取得したものである場合は、証明書を確認できます。

証明書には、証明書の所有者に関する識別情報が含まれています。受け取ったら、信頼できる機関から知っているキーの組み合わせを使用して、受け取った証明書が有効であることを確認します。したがって、証明書を発行した人を信頼していると推測できます。

3
Charlie Martin

ブラウザはCAに確認を要求しませんが、代わりにルート証明書のコピーがローカルに保存されており、標準の暗号化手順を使用して証明書が実際に有効であることを確認します。

これが、証明書に自己署名する場合、証明書が無効である理由です。技術的には要求するCAがありますが、もちろん、自己署名CAをコンピューターにコピーすると、自己署名証明書が信頼されます。

CACert.orgにも同じ問題があり、有効な証明書がありますが、ブラウザのリストにルート証明書がないため、ユーザーがルートCAをダウンロードしてブラウザに追加するまで、証明書は警告を生成します。

0
X-Istence