WCF : Could not establish trust relationship for the SSL/TLS secure channel for localhost

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 Section 3.1中指定(后来在 RFC 6125 中)。

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

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

If a subjectAltName extension of type dNSName is present, that MUSTbe used as the identity. Otherwise, the (most specific) Common Namefield in the Subject field of the certificate MUST be used. Althoughthe use of the Common Name is existing practice, it is deprecated andCertification Authorities are encouraged to use the dNSName instead.

[...]

In some cases, the URI is specified as an IP address rather than ahostname. In this case, the iPAddress subjectAltName must be presentin the certificate and must exactly match the IP in the URI.

您的服务器可能在内部响应多个主机名和 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)主题备用名称条目。 (考虑到这是一个私有(private)地址，这种情况不太可能发生。)

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