How to solve "Could not establish trust relationship for the SSL/TLS secure channel with authority"


Really thought I had this issue fixed, but it was only disguised before.

I have a WCF service hosted in IIS 7 using HTTPS. When I browse to this site in Internet Explorer, it works like a charm, this is because I have added the certificate to the local root certificate authority store.

I'm developing on 1 machine, so client and server are same machine. The certificate is self-signed directly from IIS 7 management snap in.

I continually get this error now...

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

... when called from client console.

I manually gave myself permissions and network service to the certificate, using findprivatekey and using cacls.exe.

I tried to connect to the service using SOAPUI, and that works, so it must be an issue in my client application, which is code based on what used to work with http.

Where else can I look I seem to have exhausted all possibilities as to why I can't connect?

8/31/2015 6:49:57 AM

Accepted Answer

As a workaround you could add a handler to the ServicePointManager's ServerCertificateValidationCallback on the client side:

System.Net.ServicePointManager.ServerCertificateValidationCallback +=
    (se, cert, chain, sslerror) =>
            return true;

but be aware that this is not a good practice as it completely ignores the server certificate and tells the service point manager that whatever certificate is fine which can seriously compromise client security. You could refine this and do some custom checking (for certificate name, hash etc). at least you can circumvent problems during development when using test certificates.

11/14/2013 9:33:42 AM

When I have this problem it is because the client.config had its endpoints like:


but the certificate was expecting

Changing the endpoints to match the FQDN of the server resolves my problem. I know this is not the only cause of this problem.


the first two use lambda, the third uses regular code... hope you find it helpful

            //Trust all certificates
            System.Net.ServicePointManager.ServerCertificateValidationCallback =
                ((sender, certificate, chain, sslPolicyErrors) => true);

            // trust sender
                = ((sender, cert, chain, errors) => cert.Subject.Contains("YourServerName"));

            // validate cert by calling a function
            ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(ValidateRemoteCertificate);

    // callback used to validate the certificate in an SSL conversation
    private static bool ValidateRemoteCertificate(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors policyErrors)
        bool result = false;
        if (cert.Subject.ToUpper().Contains("YourServerName"))
            result = true;

        return result;

Your problem arises because you're using a self signed key. The client does not trust this key, nor does the key itself provide a chain to validate or a certificate revocation list.

You have a few options - you can

  1. turn off certificate validation on the client (bad move, man in the middle attacks abound)

  2. use makecert to create a root CA and create certificates from that (ok move, but there is still no CRL)

  3. create an internal root CA using Windows Certificate Server or other PKI solution then trust that root cert (a bit of a pain to manage)

  4. purchase an SSL certificate from one of the trusted CAs (expensive)


A one line solution. Add this anywhere before calling the server on the client side:

System.Net.ServicePointManager.ServerCertificateValidationCallback += delegate { return true; };

This should only be used for testing purposes because the client will skip SSL/TLS security checks.


I encountered the same problem and I was able to resolve it with two solutions: First, I used the MMC snap-in "Certificates" for the "Computer account" and dragged the self-signed certificate into the "Trusted Root Certification Authorities" folder. This means the local computer (the one that generated the certificate) will now trust that certificate. Secondly I noticed that the certificate was generated for some internal computer name, but the web service was being accessed using another name. This caused a mismatch when validating the certificate. We generated the certificate for computer.operations.local, but accessed the web service using When we switched the URL to the one used to generate the certificate we got no more errors.

Maybe just switching URLs would have worked, but by making the certificate trusted you also avoid the red screen in Internet Explorer where it tells you it doesn't trust the certificate.


Licensed under: CC-BY-SA with attribution
Not affiliated with: Stack Overflow
Email: [email protected]