0

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

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?

EDIT:

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);
}

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 is hard to play with, I say.

Bahamut
  • 1,929
  • 8
  • 29
  • 51
  • Usage of the same certificate means nothing in trust chain. Show how do you call the service. – Ladislav Mrnka Jan 13 '12 at 15:20
  • Are you trying to access the second service using an URL like `https://localhost/...` and is that certificate issued to `localhost`? – Bruno Jan 13 '12 at 15:44
  • @Bruno yes. i've tried 'localhost' and an internal ip address with their respective certificates to no avail. – Bahamut Jan 13 '12 at 16:39
  • What will happen if you access the service .svc file from IE with URL used in your configuration? Will you get any warning about certificate? – Ladislav Mrnka Jan 13 '12 at 16:52
  • @Bahamut: is the certificate issued for the IP address you're trying to access or for `localhost` if you're using that name (that wouldn't necessarily make a lot of sense)? Is there a Subject Alternative Name (IP) entry for the IP address if that's what you're using? – Bruno Jan 13 '12 at 17:08
  • @LadislavMrnka via IE, yes. There's still a warning but I haven't run into a problem using the first WCF on a silverlight app running in HTTPS so I didn't think there would be a difference with calling a second similar web service. – Bahamut Jan 13 '12 at 17:53
  • @Bruno actually I made self-signed certificates issued to localhost and another one issued to the internal IP being used. Both failed for what I'm trying to achieve. – Bahamut Jan 13 '12 at 17:55
  • @Bahamut: as explained in my answer (a) you need this self-signed cert to be trusted (imported with the trusted CA certs) and (b) there *must* be an *IP* Subject Alt Name entry if you're using an IP address. – Bruno Jan 13 '12 at 18:01
  • possible duplicate of [Could not establish trust relationship for SSL/TLS secure channel -- SOAP](http://stackoverflow.com/questions/703272/could-not-establish-trust-relationship-for-ssl-tls-secure-channel-soap) – jww Aug 15 '14 at 20:54

1 Answers1

6

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

  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).

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).

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:

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.

[...]

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.

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.

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.

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.)

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.

Community
  • 1
  • 1
Bruno
  • 119,590
  • 31
  • 270
  • 376
  • I've added the certificates to the trusted root certificates using mmc but I'll try double checking it. As for the localhost/IP address thing, I can access both web services using any of the 2 formats for the endpoint. I'll try recreating the certificates, assigning to pools and test things again to check for possible causes of the problem. – Bahamut Jan 13 '12 at 17:59
  • Make sure the cert is trusted in the machine's store. If you're testing your service with a web-browser, they can be more relaxed about the IP SAN check. – Bruno Jan 13 '12 at 18:03