Question

设置是我在相同的HTTPS网站上使用相同的应用程序池和证书托管2个类似的WCF应用程序。

现在，第一个WCF应用程序在某个函数上调用第二个WCF。在第一个WCF上调用第二个WCF后，抛出异常

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

我见过类似的问题，但不同之处在于我的工作应该有效，因为它使用相同的证书。可能会发生什么？

编辑：

基本上就是第一个WCF中方法中第二个WCF的调用方式，

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

第二个WCF的第一个WCF的web.config端点有这样的东西：

...
<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网站的客户需要验证有关其证书的两件事：

他们必须检查证书是否为真品，由受信任的机构颁发（并且有效用于此目的）。这是PKI模型，在RFC 5280中指定。
他们必须检查证书是否已发给他们试图联系的实体。这是主机名验证，在RFC 2818 Section 3.1（以及后面的RFC 6125）中指定。

通过配置客户端设置信任锚（可信CA证书）来解决PKI验证。如果您的证书是由您的操作系统默认信任的CA颁发的，则您不需要执行任何操作。如果您必须自己安装CA证书，请确保它也在计算机的商店（而不仅仅是用户的商店）中启用，因为您的应用程序可能作为服务运行（而不是在特定用户）。

身份验证依赖于您尝试联系的身份（主机名或IP地址）以及颁发证书的身份。他们必须匹配。规则在RFC 2818 Section 3.1中，特别是：

如果存在类型为dNSName的subjectAltName扩展名，则必须   用作身份。否则，（最具体的）通用名称   必须使用证书的Subject字段中的字段。虽然   使用Common Name是现有的做法，它已被弃用   鼓励证书颁发机构改为使用dNSName。

[...]

在某些情况下，URI被指定为IP地址而不是a   主机名。在这种情况下，必须存在iPAddress subjectAltName   在证书中，必须与URI中的IP完全匹配。

您的服务器可能在内部响应多个主机名和IP地址，例如www.example.com，192.168.1.100，localhost，127.0.0.1。您的证书必须对您尝试与之联系的主机/ IP地址有效。

将证书颁发给localhost或127.0.0.1很少有意义，所以我怀疑这是你拥有的，并且由于这个原因，没有必要用https://localhost/...配置你的客户端。

可能有192.168.1.100的证书，但它必须有一个 IP （不是DNS）此IP地址的主题备用名称条目。（考虑到它是一个私人地址，情况就不太可能了。）

您可能需要将服务配置为使用可见主机名（可能颁发证书的主机名）：www.example.com（或其他任何名称）。如果您在反向NAT后面托管此服务，可能会出现问题。

WCF：无法为localhost建立SSL / TLS安全通道的信任关系

1 个答案: