通常のHTTPリクエストから始めて、デジタル認証全体を理解する
私はデジタル署名とデジタル認証の違いと、それらが全体としてどのように高レベルの観点で連携するかを理解しようとしています。私の理解が間違っている場合、ここの教祖が私を指し示すことを願っています。
ユーザーがウェブサイトにアクセスする場合、ユーザーとウェブサイト間の通信を暗号化するために、対称鍵が使用されます。
*クライアントとサーバーの両方で対称キーを使用するには、対称キーの作成に関する情報を非対称キーを使用して暗号化する必要があります。
ただし、最初に、Webサーバーの信頼性を確認する必要があります。したがって、Webサーバーはユーザー/クライアントにデジタル証明書を送信します。デジタル認証の内部には、2）で非対称暗号化に使用するためにWebサーバーが使用する公開鍵が含まれています。
このデジタル証明書は、認証局によって発行されており、Webサーバー/ドメインが実際に属していると思われるユーザーが実際に属していることを確認および検証します。
*ただし、デジタル認証の信頼性と完全性をどのように証明するのですか？整合性を保つために、デジタル証明書はハッシュされ、元の証明書と一緒に送信されます。信頼性のために、ハッシュされたデジタル証明書はCAの秘密鍵で署名されています。
*デジタル証明書がCAの秘密キーで署名されている場合、CAの公開キーを取得するにはどうすればよいですか？私の全体的な考えは、CAからの公開鍵が多くのブラウザーにプリインストールされているということです。
CAの公開鍵を使用して、デジタル署名されたハッシュ/証明書が復号化され、元のハッシュが生成されます。次に、クライアントは受信した証明書をハッシュして、元のハッシュと比較します。 2つのハッシュ結果が一致した場合、証明書は改ざんされていません。
デジタル証明書を使用すると、Webサーバーが使用する公開鍵がWebクライアント/ユーザーによって取得されます。次に、Webクライアント/ユーザーはこの公開鍵を使用して、対称鍵を構築する情報をWebサーバーに暗号化します。
対称鍵が既知であり、両側で作成されているため、暗号化通信を開始できます。
質問：
私の理解は正しいですか？
2 *の場合、セッションキーはWebクライアントによって作成され、直接使用（暗号化）するためにWebサーバーに送信されますか、それとも、同じセッションキー（Diffie Hellmanアルゴリズム？）
5 *については、これまでにデジタル証明書を申請したことがありません。 CAがデジタル証明書を発行するとき、本当にデジタル証明書を発行しますか？または、デジタル署名された証明書のハッシュを発行するだけですか。
それ以外の場合、CA秘密鍵なしでデジタル証明書（オリジナル）とそのデジタル署名されたハッシュバージョンをどのように送信しますか？
6 *の場合、CAの公開鍵がブラウザーにプリインストールされているという理解は正しいですか？
クライアントはウェブサーバーで認証する必要がありますか？ （私はクライアントに証明書をウェブサーバーに送信させることも読んだ）。
Webクライアントのトラストストアには何が置かれ、Webサーバーのキーストアには何が置かれますか？
まず、いくつかの用語を混乱させていると思います。用語は「デジタル証明書」、「証明書」、または単に「証明書」です。 「デジタル認証」ではありません。あなたが本当に「デジタル認証」を意味するなら、この答えはおそらく間違っています。
- はい。対称暗号化アルゴリズムは非対称暗号化アルゴリズムよりもはるかに高速であるため、対称暗号鍵はバルク暗号化に使用されます。
- いいえ、これは保証ではありません。必要なのは、サーバーとクライアントが共有シークレットについて合意することだけです。 Diffie-Hellman鍵交換 を使用することで、暗号化を必要とせずに共有秘密に同意できます。アルゴリズムの詳細を読んだり、暗号化を必要とせずにDHキー交換によって共有秘密を合意できることを信頼したりできます。 DHは、共有シークレットに同意するために頻繁に使用されます（ほとんどの場合、統計はありません）。
- はい
- はい
- はい。 証明書チェーン は、すべての証明書が改ざんされていないことを証明するために使用されます。
- 信頼できるCA証明書はWindowsにインストールされています。 IEはWindowsのものを使用しますが、ChromeとMozillaは独自の信頼できるCA証明書のセットをインストールします。
- OK。あなたはほとんどここで正しいです。一部のデジタル署名アルゴリズムは、メッセージのハッシュを秘密鍵で暗号化することによって機能します。他のアルゴリズムは他のトリックを行います（私は詳細に精通していません）が、まったく同じではありません。だから数字
7は「署名はその後クライアントによって検証される」と最もよく言われます。通常、これはハッシュと非対称暗号化を意味しますが、常にそうとは限りません。 - 繰り返しますが、違います。 Diffie-Hellman鍵交換が一般的に使用されます（
2上記）。 - はい！
箇条書きの質問について。
私の理解は正しいですか？
主に-上記の修正を行いました。
for 2 *は、Webクライアントによって作成され、直接使用（暗号化）するためにWebサーバーに送信するセッションキーです。または、同じセッションキーを使用して両側にある情報を交換することによって設定されます（Diff hellmanアルゴリズム？）
上記のDiffie Hellman。
5 *については、デジタル証明書を申請したことがありません。 CAがデジタル証明書を発行するとき、本当にデジタル証明書を発行しますか？または、証明書のデジタル署名されたハッシュを発行するだけです。
CAは、署名リクエストほど多くの証明書を発行しません。これは通常、CAに 証明書署名要求またはCSR を送信することで行われます。証明書またはキーを生成するほとんどのツールには、CSRを生成するためのオプションがあります。
それ以外の場合、CA秘密鍵なしでデジタル証明書（オリジナル）とそのデジタル署名されたハッシュバージョンをどのように送信しますか？
ここで何を言っているのかわかりません。おそらく私は上で答えましたか？
6 *については、CAの公開鍵がブラウザーにプリインストールされているという私の理解は正しいですか？
上記の回答では、ブラウザまたはOSに付属しています。 Javaも独自のリストを保持していると思います。他のいくつかの一般的なアプリも同じことをしているでしょう。
クライアントはウェブサーバーで認証する必要がありますか？ （私はクライアントに証明書をウェブサーバーに送信させることも読んだ）.
これはオプションのステップです。ほとんどのアプリケーション（Amazonや銀行など）では、クライアントであるあなたは、安全なHTTPS接続を確立してから、サイトに認証を行い、名前とパスワードを提供します。一部のサイトでは、2要素認証も許可されています。 SSLの 相互認証（別名：双方向認証） は、SSLハンドシェイク中にクライアントがサーバーに対して認証できるようにするSSLの一部です。これを行うには、クライアントに証明書と秘密鍵が必要であり、その証明書はサーバーに事前登録されている必要があります。 （これらの証明書にはCAがないことに注意してください。ブラウザは証明書のコピーを取得し、それを信頼するよう指示されたため、証明書を信頼します。）2way authの便利な部分は、魔法によって行われることです。覚えたり入力したりする厄介なパスワードはありません。 （本当に）不便な点は、すべてのブラウザー（モバイルと考えます）全体で証明書と秘密鍵のコレクションを管理する必要があるのが面倒なことです。場合によっては、クライアント証明書（つまり、2way認証）も2要素認証プロセスの2番目の要素として使用されます。私の経験では、2way認証は、ユーザーが（ほぼ）常に同じコンピューターを使用する高セキュリティ環境で最も使用されています。
Webクライアントのトラストストアに何を入れ、Webサーバーのキーストアに何を入れますか？
2way認証を使用する場合、トラストストア/キーストアに何が入れられるのですか？ 2way認証の場合、クライアントのトラストストアには何も置かれません。証明書とそのキーは通常、キーストアまたはその他の安全な、通常は暗号化されたデータストアに保持されます。また、2way認証のためにサーバーのキーストアに入るものはありません。サーバーが行う必要があるのは、証明書のコピーを保持し、それを適切なユーザーに関連付けることだけです。これは通常、データベースで行われます。
多分あなたは標準のSSL接続のためにトラストストア/キーストアに何を入れるのか尋ねていますか？ルートCA証明書は、クライアントのトラストストアに入ります。これは通常、ブラウザー/ OSプロバイダーによって行われ、ユーザーがこれを変更する必要はありません。自己署名証明書（つまり、CAなし）をデプロイする場合、またはWebプロキシを実行している場合は、クライアントのトラストストアに新しい証明書を追加する必要がある場合があります。サーバーの秘密鍵は、その鍵ストアに保管されます。便宜上、頻繁に証明書もそこに保存されます。
ユーザーがウェブサイトにアクセスするとき、ユーザーとウェブサイト間の通信を暗号化するために、対称鍵が使用されます。
はい。
*クライアントとサーバーの両方で対称キーを使用するには、対称キーの作成に関する情報を非対称キーを使用して暗号化する必要があります
はい、diffie-hellmanでない限り。
しかし、第一に、ウェブサーバーの信頼性を確認する必要があります。したがって、ウェブサーバーはユーザー/クライアントにデジタル証明書を送信します。デジタル認証の内部には、2）で非対称暗号化に使用するためにWebサーバーが使用する公開鍵が含まれています。
はい。
このデジタル証明書は認証局によって発行されており、Webサーバー/ドメインが本当に長い間誰に属しているかを確認するためのチェックと検証を行います。
はい-これは証明書のレベルによって異なります。要求された証明書がドメイン検証済み（DV）、組織検証済み（OV）、または拡張検証（EV）証明書のいずれであるかによって、実行されるチェックが決まります。
*ただし、デジタル証明書の信頼性と完全性をどのように証明するのですか？完全性のために、デジタル証明書はハッシュされ、元の証明書と一緒に送信されます。信頼性のために、ハッシュされたデジタル証明書はCA秘密鍵で署名されています。
はい、証明書にはブラウザによってダウンロードされた署名が含まれています。
*デジタル証明書がCA秘密鍵で署名されている場合、CAの公開鍵を取得するにはどうすればよいですか？私の全体的な考えは、CAからの公開鍵が多くのブラウザーにプリインストールされているということです。
ブラウザーが証明書を信頼するには、CAの公開鍵がオペレーティングシステムまたはブラウザーの証明書ルートストアにある必要があります。 Internet ExplorerおよびChromeはOSのストアを使用しますが、Firefoxには独自のストアがあります。
CAの公開鍵を使用して、デジタル署名されたハッシュ/証明書が復号化され、元のハッシュが生成されます。次に、クライアントは受信した証明書をハッシュして、元のハッシュと比較します。 2つのハッシュ結果が一致した場合、証明書は改ざんされていません。
結構です。ハッシュ、暗号化、署名を混同しないでください。 Webサイトの公開証明書は、CAの秘密鍵による（または中間CAによる）signedです。チェーンが信頼できるルート証明書になる限り、すべてが良好です。例えば.
Site CA --signed-by-> Intermediary CA --signed-by-> Root CA
CAの公開鍵を使用して、誰でも署名がハッシュされた証明書と一致することを確認できます。公開鍵暗号は、数式で「トラップドア関数」を利用します。署名が公開鍵を使用して秘密鍵によって生成されたことを確認することは簡単ですが、CAの秘密鍵がないと署名を生成することは計算上不可能です。
デジタル証明書を使用すると、Webサーバーが使用する公開鍵がWebクライアント/ユーザーによって取得されます。次に、Webクライアント/ユーザーはこの公開鍵を使用して、対称鍵を構築する情報をWebサーバーに暗号化します。
はい、プレマスターシークレットは公開鍵で暗号化されています。 Diffie-Hellmanの場合、代わりに公開鍵を使用して共有秘密に署名します。
5 *については、デジタル証明書を申請したことがありません。 CAがデジタル証明書を発行するとき、本当にデジタル証明書を発行しますか？または、証明書のデジタル署名されたハッシュを発行するだけです。
はい。証明書と、証明書のハッシュから計算された署名を受け取ります。
それ以外の場合、CA秘密鍵なしでデジタル証明書（オリジナル）とそのデジタル署名されたハッシュバージョンをどのように送信しますか？
秘密鍵は保持できます。証明書に署名を付けるには、CAに送信する証明書署名要求（CSR）を生成します。証明書に署名したら、署名済みバージョンをサーバーにインストールして、以前に生成された秘密鍵とペアにすることができます。
一部のCAは秘密鍵を生成しますが、セキュリティのために、自分で生成し、CSRを送信することをお勧めします。
クライアントはウェブサーバーで認証する必要がありますか？ （私はクライアントに証明書をウェブサーバーに送信させることも読んだ）.
はい、クライアント証明書を使用して、Webサーバーでクライアントを認証できます。これは、暗号化ではなく、認証のみを目的としています。
Webクライアントのトラストストアに何を入れ、Webサーバーのキーストアに何を入れますか？
Webクライアントは証明書を送信し、Webサーバーは公開鍵を検証して、信頼できるCAによって署名されていることを確認できます。秘密鍵の所有を証明するものとして、クライアントは、サーバーが公開鍵によって確認できるハンドシェイクメッセージにも署名します。