web-dev-qa-db-ja.com

証明を目的としたSSL証明書とは何ですか?

有名なプロバイダーからSSL証明書を取得した場合、それは私のサイトについて何を証明しますか?

これが私が知っていることです:

  • アリスとボブの両方が公開鍵と秘密鍵を持っていると仮定します
  • アリスがボブの公開キーで何かを暗号化する場合、彼女はボブだけが(彼の秘密キーを使用して)それを解読できることを保証します
  • アリスが自分の秘密鍵で何かを暗号化した場合、誰でも(彼女の公開鍵を使用して)それを復号化できますが、それは彼女によって暗号化されたことがわかります
  • したがって、アリスが最初に自分の秘密鍵でメッセージを暗号化し、次にボブの公開鍵で暗号化した場合、彼女はボブだけがそれを復号化でき、ボブは自分からのメッセージであることを知ることができます。

証明書に関して、私が思うことはここにあります(更新):

  • 証明書の要求を生成します。そのリクエストで、私は自分の公開鍵と自分自身についてのたくさんの情報を入れました。
  • 証明書発行者(理論的には)が私をチェックして、自分が誰であるかを知っていることを確認します:直接話をしたり、運転免許証や網膜スキャンなどを見たりします。
  • 彼らが満足している場合、証明書発行者は自分のリクエストを秘密鍵で暗号化します。公開鍵を使用して暗号化を解く人は誰でも、その公開鍵に含まれている情報を保証していることを知っています。公開鍵は自分のものであり、記載されている情報は私について真実であることに同意します。この暗号化された保証は、彼らが私に発行する証明書です。
  • Https経由で私のサイトに接続すると、証明書が送られてきます。
  • ご使用のブラウザーには、その情報がインストールされているため、発行者の公開鍵はすでに認識されています。
  • お使いのブラウザーは、発行者の公開鍵を使用して、私が送信したものを復号化します。発行者の公開鍵がdecryptに機能するという事実は、発行者の秘密鍵がencryptに使用されたことを証明し、したがって、発行者が実際にこの証明書を作成したことを証明します。
  • 復号化された情報の中に私の公開鍵が含まれていますが、これは保証されています。これを使用して、送信するデータを暗号化します。

そうですか?そうでない場合、誰かがステップを非常に明確にレイアウトできますか?

37
Nathan Long

重要な理論:基本的に正しいが、認証は通常、データ自体ではなく、データの暗号化された安全なハッシュを暗号化することによって行われます。

SSL証明書に対するCAの署名は、CAが証明書の資格情報が所有者と一致することを保証するためにある程度の注意を払ったことを示している必要があります。その勤勉さはさまざまですが、最終的なポイントは、彼らが署名した証明書は、その上で指定されたエンティティに属しているということです。

参照 http://en.wikipedia.org/wiki/Digital_signature#Definition

17
Jeff Ferland

公開鍵証明書は、公開鍵、識別子、および場合によっては他の属性間の署名された組み合わせです。このドキュメントに署名した人は、パスポート発行機関がパスポート内の画像と名前の間のバインディングを主張するのと同じように、公開鍵と識別子およびこれらの属性の間のバインディングの信頼性を効果的に主張します。情報(国籍、生年月日など)。

最初に、用語に関するいくつかの説明:

  • 厳密には「SSL証明書」というものはありません。ほとんどの場合、これは「SSL/TLSに使用されるX.509証明書」の短い表現です。 (SSL/TLSは、 OpenPGP証明書 など、他のタイプの証明書を使用することもできますが、これはあまり一般的ではありません。)

  • 「暗号化」と「復号化」の使い方はここでは正しくありません。公開鍵暗号では:

    • 秘密鍵は、署名および解読/復号化に使用されます。
    • 公開鍵は、署名の検証および暗号化/暗号化に使用されます。

    TLS仕様 の用語集を参照してください。

    公開鍵暗号:2つの鍵の暗号を使用する暗号化技術のクラス。公開鍵で暗号化されたメッセージは、関連付けられた秘密鍵でのみ復号化できます。逆に、秘密鍵で署名されたメッセージは、公開鍵で検証できます。

    RSAに関する限り、これらの操作はほぼ同じであるため、用語のこの違いは重要ではないように見えるかもしれません(実際、OpenSSLでRSA_private_encryptと呼ばれる基本的なルーチンを見つけます)が、(a)これはDSAに取り組み、(b)この根本的な違いを理解しないと、全体的なセキュリティスキームに関する限り、ミスをする可能性があります。

    特に、暗号化の目的は何かを隠すことです。ここで「秘密鍵による暗号化」について話すとき、公開鍵は誰にでも知られているので意味がありません。さらに、すべての人( TBSCertificate構造 を参照)は誰にでも見えるように明確に存在するため、発行者の公開鍵はこの発行者が署名した証明書の内部を調べる必要はありません。ここには何も隠されていません。

    (RSAで署名するために行われることは、実際には暗号化とほぼ同じ操作ですが、秘密鍵を使用して、署名するメッセージの暗号ダイジェストに適用されます。通常、最近の証明書ではSHA-1を使用して行われます。)

サーバー証明書が証明しようとしているのは、CAがホスト名と証明書要求(具体的には、証明書要求の公開鍵)の間のバインディングを何らかの方法で検証したことです。少なくとも、ドメイン名の所有者に電子メールを送信します(ドメイン検証済み証明書の場合)。 (検証モードの違いについては、 こちら を参照してください。)

発行される証明書の内容は、クライアントが証明書を検証および検証する方法を定義するRFC 3280/RFC 5280に準拠している必要があります。これは、どの属性を使用できるか、特に(拡張)主要な使用属性を通常定義します。 「TLSサーバー」。

その結果、X.509サーバー証明書は一緒にバインドされます。

  • 公開鍵(秘密鍵がある場合)。
  • 発行者名(CA証明書のサブジェクトDN)。
  • サブジェクトの別名拡張またはサブジェクト識別名の共通名に含まれるサーバー名(RFC 2818セクション3.1またはRFC 6125に準拠)。
  • 使用拡張。
  • おそらく他の拡張機能(重要かどうかに関係なく)。 EV証明書ポリシー。

これはすべて、X.509証明書の TBSCertificate structure に配置されます。次に、この構造は暗号化ハッシュアルゴリズム(SHA-1など)を使用してダイジェストされ、CAの秘密キーを使用して署名されて、署名(signatureValueCertificate)が形成されます。

証明書が使用されている場合、クライアントはこの署名を確認できます(既知のCAの公開鍵を使用するか、既知のトラストアンカーの1つへの複数のCA証明書を使用して証明書パスを構築する)、使用属性がSSLと互換性があることを確認します/ TLSの使用方法、および要求されたホスト名が発行されたものと一致することを確認します。

7
Bruno

秘密鍵は、メッセージの復号化と署名の両方に使用されるただ1つの鍵であるとは限らないことを、他のすべての回答とともに指摘する必要があります。これらは2つの別々のキーである必要があります。これにより、各人に4つのキーが作成されます。

公開暗号化キー-私に送信するデータを暗号化するために使用されます。

Private Decryption Key-公開暗号化キーを使用して暗号化されたメッセージを復号化するために使用されます。

プライベート署名キー-他の人に送信するメッセージに署名するために使用されます。

Public Verify Key-メッセージが実際に私によって署名されたことを確認するために使用されます。

これに個別のキーを使用する理由はいくつかあります。詳細については このディスカッション を参照してください。

3
Oleksi