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. 他们必须检查证书是否真实，由受信任的机构颁发（并且为此目的有效）。这是 PKI 模型，在 RFC 5280 中指定。
2. 他们必须检查证书是否已颁发给他们尝试联系的实体。这是主机名验证，在RFC 2818 Section 3.1（以及后来在RFC 6125）中指定。

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

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

如果存在 dNSName 类型的 subjectAltName 扩展，则必须 用作身份。否则，（最具体的）通用名称 必须使用证书的主题字段中的字段。虽然 通用名称的使用是现有的做法，它已被弃用并且 鼓励证书颁发机构改用 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 之后托管此服务，则可能会出现问题。