WCF：localhostのSSL/TLSセキュアチャネルの信頼関係を確立できませんでした

Question

同じアプリケーションプールと証明書を使用して、同じHTTPS Webサイトに2つの同様のWCFアプリケーションをホストしています。

最初のWCFアプリケーションは、特定の関数で2番目のWCFを呼び出します。最初に二WCFを呼び出した後、例外が

"Could not establish trust relationship for the SSL/TLS secure channel..." 

を投げます、私は同様の質問を見てきましたが、違いは、同じ証明書を使用していますので、鉱山が動作しなければならないことです。何が起こっているのでしょうか？

EDIT：

：二WCFはこのような何かを持っているため

は基本的に、ここで最初のWCFのweb.configエンドポイントは

public void SomeMethod(string parameter) 
{ 
    SecondServiceClient svc2 = new SecondServiceClient ("BasicHttpBinding_IService2"); 
    svc2.DoWork(parameter); 
} 

、二WCFは、最初のWCFのメソッド内で呼ばれている方法です

... 
<client> 
    <endpoint address="https://192.168.1.100/MyService2/Service2.svc" 
    binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IService2" 
    contract="SecondService.IService" name="BasicHttpBinding_IService" /> 
</client> 
... 

HTTPSは遊びにくいと私は言う。

Answer 1

HTTPSサイトにアクセスするクライアントは、その証明書に関する二つのことを確認する必要があります：

1. 彼らは証明書が本物であることを確認しなければならない、（この目的のために、有効な）信頼された機関によって発行されました。これはRFC 5280で指定されたPKIモデルです。
2. 証明書が連絡しようとしているエンティティに発行されたことを確認する必要があります。これはRFC 2818 Section 3.1（以降はRFC 6125）で指定されたホスト名検証です。

PKI検証は、クライアントセットにトラストアンカー（信頼できるCA証明書）を設定することによって対処されます。 OSによってデフォルトで信頼されているCAによって証明書が発行された場合は、何もする必要はありません。 CA証明書を自分でインストールする必要がある場合は、マシンのストア（ユーザーのストアだけでなく）でも有効になっていることを確認してください。アプリケーションがサービスとして（特定のユーザーではなく）実行されている可能性があります。

身元確認は、連絡しようとしている身元（ホスト名またはIPアドレス）と証明書の発行IDに依存します。一致する必要があります。ルールは、特に、RFC 2818 Section 3.1である：

型のdNSNameのsubjectAltName拡張が IDとして使用しなければならない、存在する場合。それ以外の場合は、証明書のSubjectフィールドの（最も固有の）Common Name フィールドを使用する必要があります。 共通名の使用は既存の方法で行われますが、推奨されておらず、代わりに 認証機関にdNSNameを使用することをお勧めします。いくつかのケースでは

[...]

、URIは、IPアドレスではなく ホスト名として指定されています。この場合、iPAddressのsubjectAltNameは証明書の中に でなければならず、URIのIPと正確に一致する必要があります。

サーバーが127.0.0.1、localhost、192.168.1.100、たとえばwww.example.comのために、複数のホスト名とIPアドレスに内部的に応答することができます。証明書は、接続しようとしているホスト/ IPアドレスに対して有効である必要があります。

それはめったにlocalhostまたは127.0.0.1に発行された証明書を持っていることは理にかなっていないので、私はそれはあなたが持っているものだ疑い、そしてこの理由のためにhttps://localhost/...を使用してクライアントを構成しない点はありません。

192.168.1.100の証明書を持つことはできますが、IP（DNSではありません）のサブジェクト代替名エントリが必要です。

可視のホスト名（証明書が発行されたと思われる）を使用するようにサービスを設定する必要がある可能性があります。www.example.com（またはそれが何であれ）。リバースNATの背後にこのサービスをホスティングしている場合、問題が発生する可能性があります。