4

私はSSL認証を初めて使用し、SSLを使用して信頼境界を越えて2つのアーキテクチャコンポーネントを認証する必要があります（両方のコンポーネントを制御できます）。サーバーとクライアントの両方が証明書を持っている双方向SSL認証が必要になると思います。

証明書は自己署名できますか？（つまり、ベンダーによって署名されており、そもそもSSLを使用しても無効になりませんか？または、証明書のIDを確認するためにサードパーティの検証サービスが必要ですか？）

サーバーとクライアントの両方の公開鍵と秘密鍵に関して、ハンドシェイクはどのように機能しますか？

証明書を使用するようにIISでサーバーを構成し、要求とともにクライアント証明書を送信する必要があります（ほとんどの場合、WCFを使用した構成によるものですか？）が、これを機能させるために他に必要なタスクはありますか？

4

3 に答える 3

3

私はEJPの回答に同意しますが、別の回答を受け入れたので、自己署名証明書の問題についてさらに詳しく説明します。

サーバーで自己署名証明書を使用することができます。この証明書を信頼するために、すべての潜在的なクライアントを構成する必要があります。これは、証明書を（秘密鍵なしで）各マシンの信頼できるストアにインポートするか、ブラウザーの信頼できる証明書リポジトリ内にインポートすることで実行できます（たとえば、Firefoxは、実行しているOSに関係なく独自の証明書を使用します）。ここでの自己署名サーバー証明書は、主にカスタムCA証明書の特殊なケースであり、各クライアントは使用する可能性のある各サーバーについて知る必要があります（自己署名証明書を取り消すことができないという欠点があります）。これは問題ありませんが、実際には、マシンの数が少ない場合、これはすぐに問題になる可能性があります。

主な問題は、クライアント証明書としての自己署名証明書に関するものです。

クライアント証明書認証はサーバーによって開始され、サーバーはTLS証明書要求メッセージをクライアントに送信します。このメッセージには、受け入れても構わないと思っている認証局の名前のリストが含まれています。次に、クライアントはこのリストを使用して、送信する証明書を選択します。クライアントは、このCAリストの名前の1つと一致する発行者DNを持つ証明書（秘密鍵を持っている）を探します（中間CAの場合は、証明書チェーンを使用することもできます）。このCAリストにある発行者DNへのリンクを作成するには、証明書が必要です）。

ほとんどのクライアントは、これらの条件に一致する証明書が見つからない場合、クライアント証明書をまったく送信しません。これは、自己署名クライアント証明書を使用しようとする場合の最大の問題になります。

この問題を回避する方法は、サーバーに空のリストを送信させることです。これにより、どの証明書を選択するかについてクライアントにより多くの自由が与えられます（それを受け入れるかどうかを選択するのはサーバー次第ですが、とにかく常にそうなります）。これはTLS1.1で明示的に許可されており、以前のバージョン（SSLv3 / TLS 1.0）はこのトピックについては言及していませんが、実際には、私が知る限り、ほとんどのSSLv3 /TLS1.0スタックでも正常に機能します。（これは、たとえば、ブラウザによって自動証明書選択が行われる場合でも、その自動選択を正しく行うことが困難になるため、不格好な相互作用につながる可能性があります。）

Javaは、TLS証明書要求メッセージで空のCAリストを返すX509TrustManagerようにカスタマイズできます。getAcceptedIssuers()私の知る限り、C＃/。Netでは、SslStream'sRemoteCertificateValidationCallbackには同等のものがありません。私の知る限り、このリストは、IIS/を使用する場合のマシンの信頼できる証明書リストから作成されますSslStream。（これは証明書の検証自体とは無関係であることに注意してください。サーバーがどの証明書を受け入れるかをアドバタイズするだけです。）

さらに、自己署名証明書でクライアント証明書認証を使用する場合は、この認証を実行するためにサーバーに独自の検証コールバックを実装する必要があります。簡単な例は、取得した証明書から公開鍵を抽出し、それをサーバーが持っている事前定義されたリストと比較して、その事前定義されたリストにあるユーザー名を使用することです。自己署名証明書の内容を自分が知っているものと照合する明示的な方法がない限り、自己署名証明書の内容を信頼することはできません。ただ言うコールバックを実装するreturn true;すべての認証を実行するわけではありません。誰でも同じ名前または属性と異なるキーで証明書を作成できます。（サーバーの信頼できる証明書ストアで各client-certを明示的に信頼することをお勧めしますが、TLS証明書要求メッセージでCAリストが長くなる可能性があります。）

商用CAに依存したくない場合は、独自のCAを構築してください。少し手間がかかる場合がありますが（ほとんどの場合、管理）、少なくとも、よりクリーンな結果のシステムが得られます。そのCA証明書を使用してクライアントとサーバーを構成することにより、変更を加えずに、より多くのクライアントとサーバーに拡張できるようになります。また、クライアント証明書が要求されたときの通常のCAリストの動作を利用できるようになります。

于 2012-08-07T13:11:50.323 に答える
2

自己署名は、実際には最終的にはより複雑です。両端を完全に制御できない限り、それを行わないでください。

秘密鍵は、ハンドシェイクで送信される証明書に署名するために使用されます。これにより、ピアは、送信する証明書を本当に所有しているかどうかをピアが確認できます。サーバーの秘密鍵は、一部の暗号でシャードシークレットを生成する役割も果たします。

于 2012-08-05T00:18:22.207 に答える
-4

クライアント証明書とサーバー証明書を使用した双方向認証が機能します。自己署名証明書も使用できます。ただし、両方の証明書が信頼できる機関によって署名されていないため、両方の証明書が自己署名されている場合は、クライアントとサーバーの両方で証明書の検証をバイパスする必要があります。

証明書のインストールに関しては、次のように実行する必要があります。

サーバ側

  1. LocalMachineにインストールされたServerCert.pfx->パーソナルストア

  2. ローカルマシンにインストールされたClientCert.cer->TrustedPeopleストア

クライアント側

  1. ClientCert.pfxが現在のユーザーにインストールされています->パーソナルストア

  2. ServerCert.cerがローカルマシンにインストールされている->トラステッドストア

ServerCert.cerファイルをクライアントに出荷する必要があり、クライアントはClientCert.cerを出荷する必要があります。

これで、自己署名証明書を使用していて、クライアントがサービスにアクセスしている場合、証明書の検証をバイパスする必要があります。以下のC＃のサンプルコード：

        System.Net.ServicePointManager.ServerCertificateValidationCallback = (sender, cert, chain, error) =>
                                                                                 {
                                                                                     return true;
                                                                                 };

お役に立てば幸いです。

注：セキュリティの観点から、本番環境で自己署名証明書を使用したり、証明書の検証をバイパスしたりすることはお勧めできません。

于 2012-08-06T15:59:00.303 に答える