クライアントWCFはローカルマシン上にサーバー証明書を持たずにサーバーWCFに接続できません

Question

シナリオはこれです：クライアントが2つ（WCFClient）、サーバーが1つ（WCFServer） 。私はそれらの2人の間で証明書通信が必要でした。

サーバWCFでは、クライアント証明書タイプとして証明書を使用するようにバインディングを設定しました。

<security mode="Message"> 
     <message clientCredentialType="Certificate" /> 
</security> 

また、行動のセクションで、他の設定の中で、私がテストしたい場合は、私はこのエンドポイントの振る舞い

<endpointBehaviors> 
    <behavior name="CustomBehavior"> 
    <clientCredentials> 
     <clientCertificate findValue="Client" 
          x509FindType="FindBySubjectName" 
          storeLocation="LocalMachine" 
          storeName="TrustedPeople" /> 
     <serviceCertificate>    
     <authentication certificateValidationMode="PeerTrust"/> 
     </serviceCertificate> 
    </clientCredentials> 
    </behavior> 
</endpointBehaviors> 

を追加したクライアントのWCFサービス上で

<serviceBehaviors> 
     <behavior name="Server.ServiceBehavior">     
      <serviceCredentials> 
      <clientCertificate> 
       <authentication certificateValidationMode="PeerTrust"/> 
      </clientCertificate> 
      <serviceCertificate findValue="Server" 
      storeLocation="LocalMachine" 
      storeName="TrustedPeople" 
      x509FindType="FindBySubjectName" /> 
      </serviceCredentials> 
     </behavior> 
</serviceBehaviors> 

を持っている私サービスのエラーメッセージが表示されました：

The service certificate is not provided for target 'http://blablabla...'. Specify a service certificate in ClientCredentials.

私はインターネット上で物事をチェックアウトし始めました。多くのことをしようとした後、実際に働いていた唯一のことは、私のクライアント上でこれを追加している：あなたが考えるかもしれませんが、はい、これは私は私のクライアントマシン上のサーバー証明書を必要とする意味

<serviceCertificate> 
     <defaultCertificate findValue="Server" 
          storeLocation="LocalMachine" 
          storeName="TrustedPeople" 
          x509FindType="FindBySubjectName" /> 
     <authentication certificateValidationMode="PeerTrust"/> 
     </serviceCertificate> 

。それは明らかに非常に悪いことです。 私のテスト目的では動作しますが、展開には受け入れられません。

私は本当にそのエラーメッセージを引き起こす可能性があり、解決策が何であるかを理解したいと思います。

後で編集：このプロジェクトでは、（プライベートキーを持たなくても）クライアントはサーバー証明書を持っていてはいけません。これはシステムの仕様であり、これを超えることはかなり難しいです（bureaucracyという用語で）。 クライアントWCFサービスを実行している複数のクライアントが存在し、それぞれが独自の証明書を認識している必要があります。サーバーはサーバー証明書とすべてのクライアント証明書を認識します。

Answer 1

私は実際にこの質問を忘れていましたが、その時私は解決策を見つけました。

私の実際の問題は、セキュリティ保護したい通信にbasicHttpBindingを使用していたことでした。 basicHttpBindingは、そのserviceCredential部分を使用することを意味します。 http://msdn.microsoft.com/en-us/library/ms731338(v=vs.85).aspx

システム要件のため、バインディングをwsHttpBindingに変更しました。これで、サーバー証明書をクライアントマシンに置く必要はありません。

Answer 2

hereを見ると、それは、

を読み込み認証を考えるとき、あなたは主にクライアントIDの を考えることに使用することができます。ただし、WCFのコンテキストでは、認証 は通常、相互認証を指します。相互認証ではない は、クライアントの肯定的な識別のみを許可するだけでなく、 が接続されているWCFサービスを クライアントが確実に識別できるようにします。攻撃者が WCFサービスを偽装し、クライアントの呼び出しを乗っ取って 機密データを明らかにする可能性があるため、相互認証は インターネットフェイスのWCFサービスにとって特に重要です。

使用するサービス資格情報は、選択したクライアントの 認証スキームによって大きく異なります。通常、ユーザー名または証明書 認証などのWindows以外のクライアント認証 を使用している場合は、サービス 認証とメッセージ保護の両方にサービス証明書が使用されます。Windowsクライアント 認証を使用している場合は、プロセスIDのWindows資格情報をサービス認証とメッセージ保護の両方に使用する にすることができます。

それはあなたががクライアントマシンにサーバー証明書が必要で、これは良いことではなく、悪いことであるということかように私には見えます。 を実行していないことに注意してください。は、サーバーの秘密鍵をクライアントマシンにインストールする必要があります。秘密鍵は証明書に含まれておらず、公開鍵だけです。

クライアントマシン上にサーバー証明書を持つことは、クライアントマシン上にサーバーの公開キーがあることを意味します。メリットは、クライアントが実際のサーバーと通信していることが分かっていることです。

私はWCFサービスに精通していませんが、これは証明書を使用する限り問題ありません。

Answer 3

クライアントマシンにサービス証明書を置くのはなぜ悪いですか？それは秘密鍵ではなく、その公開部分だけです。

wshttpbindingを使用する場合は、negotiateServiceCredential = trueを設定できます。この場合、クライアントはサーバー証明書を動的に取得します。価格は少し高いパフォーマンスですが、このエンドポイントは非ネットクライアントとの相互運用ができません。