您的位置: 首页  >  技术问答  >  WCF：无法为localhost建立SSL / TLS安全通道的信任关系

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

分类: 技术问答 • 2022-04-17 19:34:16
问题描述：

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

The setup is that I'm hosting 2 similar WCF app on the same HTTPS website using the same application pool and certificate.

现在第一个WCF应用程序调用关于某个功能的第二个WCF。在第一个WCF上调用第二个WCF后，抛出异常

Now the first WCF app calls the second WCF on a certain function. After calling the second WCF on the first, exception gets thrown 

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

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

I've seen similar questions but the difference is that mine should work since it's using the same certificate. What might be going on?

编辑：

基本上这里是如何在方法中调用第二个WCF第一个WCF，

basically here's how the second WCF is called inside a method in the first WCF,

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

第一个WCF的第二个WCF的web.config端点有这样的结果：

first WCF's web.config endpoint for the second WCF has something like this:

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

我说很难用HTTPS。

HTTPS is hard to play with, I say.

答

访问HTTPS网站的客户需要验证有关其证书的两件事：

A client accessing an HTTPS website need to verify two things about its certificate:


  1. 他们必须检查证书是否为真品，由受信任的机构颁发（并且有效用于此目的）。这是PKI模型，在 RFC 5280 中指定。

  2. 他们必须检查证书是否发给他们试图联系的实体。这是主机名验证，在 RFC 2818第3.1节中指定（稍后在 RFC 6125 ）。

  1. They must check that the certificate is genuine, issued by a trusted authority (and valid for this purpose). This is the PKI model, specified in RFC 5280.
  2. They must check that the certificate was issued to the entity they are trying to contact. This is the host name verification, specified in RFC 2818 Section 3.1 (and later in RFC 6125).

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

The PKI verification is addressed by configuring the client set a trust anchors (trusted CA certificates). If your certificate was issued by a CA trusted by default by your OS, you shouldn't need to do anything. If you had to install the CA certificate yourself, make sure it's also enabled in the machine's store (not just the user's store), since your application may be running as a service (and not under a specific user).

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

The identity verification relies on the identity you're trying to contact (host name or IP address) and the identity to which the certificate has been issued. They must match. The rules are in RFC 2818 Section 3.1, in particular:


如果存在类型为dNSName的subjectAltName扩展名，则必须使用
作为标识。否则，必须使用证书的Subject字段中的（最具体的）Common Name
字段。虽然
使用公共名称是现有做法，但不推荐使用它，并且鼓励
证书颁发机构使用dNSName。

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

[。 ..]

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

In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in 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地址有效。

Your server may be responding internally to multiple host names and IP addresses, for example www.example.com, 192.168.1.100, localhost, 127.0.0.1. Your certificate must be valid for the host/IP address you're trying to contact it with.

将证书颁发给 localhost 或 127.0.0.1 ，所以我怀疑你拥有的是什么，并且没有必要用 https配置你的客户端：// localhost / ... 因此。

It rarely makes sense to have a certificate issued to localhost or 127.0.0.1, so I doubt that's what you have, and there's no point configuring your client with https://localhost/... for this reason.

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

It's possible to have a certificate for 192.168.1.100, but it MUST have an IP (not DNS) Subject Alternative Name entry for this IP address. (Considering it's a private address, it's quite unlikely to be the case.)

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

It's possible that you need to configure your service to use the visible host name (the one for which your certificate was probably issued): www.example.com (or whatever it is). There might be problems if you're hosting this service behind a reverse NAT.

相关推荐