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

Question

设置是我在相同的HTTPS网站上使用相同的应用程序池和证书托管2个类似的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网站的客户端需要验证有关其证书的两件事:

1. 他们必须检查证书是否为真品,由受信任的机构颁发(并且对此有效).这是RFC 5280中指定的PKI模型.
2. 他们必须检查证书是否发给他们试图联系的实体.这是主机名验证,在RFC 2818第3.1节(以及后来的RFC 6125中)中指定.

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

身份验证依赖于您尝试联系的身份(主机名或IP地址)以及颁发证书的身份.他们必须匹配.规则在RFC 2818第3.1节中,特别是:

如果存在类型为dNSName的subjectAltName扩展名,则必须将其用作标识.否则,必须使用证书的Subject字段中的(最具体的)Common Name字段.尽管使用Common Name是现有做法,但不推荐使用它,并且鼓励证书颁发机构使用dNSName.

[...]

在某些情况下,URI被指定为IP地址而不是主机名.在这种情况下,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地址的IP(非DNS)主题备用名称条目.(考虑到它是一个私人地址,情况就不太可能了.)

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