WCF calling another WCF: Could not establish trust relationship for the SSL/TLS?

When you use self signed certificates you need to have the certificate validation return true in your client that access the WCF service.

Up vote 0 down vote favorite share g+ share fb share tw.

I have two WCF hosted on two different HTTPS websites with different certificates. WCF(a) calls WCF(b) and vice-versa with an if clause to cancel the possible infinitely loop. Every time the method of both WCF is called, it returns the error: Could not establish trust relationship for the SSL/TLS I tried installing the certificates in the Trusted Root Certificates but the error still appears.

Avoiding the WCF-calling-another-WCF is not an option, unfortunately. Any fix for this? UPDATE: I've tried hosting both in the same website and it worked so I'm thinking this is specific to the certificate being used?

So should the same certificate must be used? Or is there a possible way to use different websites with different certificates? Wcf ssl https ssl-certificate link|improve this question edited Jan 30 at 13:33 asked Jan 30 at 12:37Bahamut158112 90% accept rate.

– Richard Blewett Jan 30 at 13:28 at the moment both are using self-signed certificates. So yes, it fails whichever WCF is used. I've updated the post too.

– Bahamut Jan 30 at 13:32 Can you show the service configs - are you using message or transport security? What binding(s) are you using? – Richard Blewett Jan 30 at 14:14 the app is silverlight so i'm using basichttpbinding with transport security – Bahamut Jan 30 at 14:58.

When you use self signed certificates you need to have the certificate validation return true in your client that access the WCF service. The code is as shown below: System.Net. ServicePointManager.

ServerCertificateValidationCallback = (sender, cert, chain, error) => { return true; }; Just place this code before you invoke your service method. Also Since you have 2 services A and B calling each other the above code should be in both places when you make a call. The above is to trust the certificate as its not from a trusted certificate provider.

Doesn't work for me. But for the SO users that might stumble on this, this code is only applicable for development and testing and not for the actual release of the application, right? – Bahamut Jan 30 at 15:11 Yes.

Since you are using self signed certificates the above code applies. Is it that you are using client authentication using certificates as well – Rajesh Jan 30 at 16:10 You must NEVER ship such code in production. You are opening yourself up for man-in-the-middle attacks, which will be trivial to pull off.

– Nasko Jan 30 at 16:12 @Nasko: The code is applicable only on the client side. – Rajesh Jan 30 at 16:32 How does that change things? Certificate validation should never be disabled in production.

You could change the validation logic, but it should never be just "return true;" or you will be attackable. – Nasko Jan 30 at 19:37.

Using self signed certificates for SSL you need to be aware of the following: The certificate needs to be installed in both LocalHost\My and LocalHost\CA stores. The common name part in the subject needs to match the fully qualified domain name for the server. For self signed certificates you can use the public ip address.

The account that your service runs under must have read access to the private key of the certificate. These steps can be satisfied by hosting the services under IIS, and use IIS to generate the server certificate. Also be aware that wcf usually requires that an CRL is attached to the certificate.

But this can also be generated with certmgr.exe.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.