Could Not Establish Trust Relationship For Ssl/Tls Secure Channel - Soap

Could not establish trust relationship for SSL/TLS secure channel -- SOAP

Thoughts (based on pain in the past):

• do you have DNS and line-of-sight to the server?
• are you using the correct name from the certificate?
• is the certificate still valid?
• is a badly configured load balancer messing things up?
• does the new server machine have the clock set correctly (i.e. so that the UTC time is correct [ignore local time, it is largely irrelevent]) - this certainly matters for WCF, so may impact regular SOAP?
• is there a certificate trust chain issue? if you browse from the server to the soap service, can you get SSL?
• related to the above - has the certificate been installed to the correct location? (you may need a copy in Trusted Root Certification Authorities)
• is the server's machine-level proxy set correctly? (which different to the user's proxy); see proxycfg for XP / 2003 (not sure about Vista etc)

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

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.

C# How to solve HtppWebResponse return Could not establish trust relationship for the [SSL/TLS] secure channel?

This literally means the place where your code is running doesn't trust the certificate installed on the remote site.

Though the code you posted bypasses all authentication checks, this is not really a good practice as SSL gives you a bit of assurance that the site you're talking to is legitimate, and no one is doing a man-in-the-middle attack for example to intercept your data.

---

Diagnostic step number one is to visit that page in your browser and take a look at the certificate.

Make sure your browser thinks it's secure -- it'll tell you why it doesn't, if it doesn't. Common reasons:

1. Expired (check Valid from .. to)
2. Mismatched domain name (check both Issued To and Subject Alternative Name)
3. Issued by non-trusted authority

In the case of (1) and (2), it's really a server issue the remote service needs to deal with.

With (2) sometimes people only issue a certificate for "www.example.com" and not "example.com" (or "*.example.com", which doesn't include "example.com") so an easy work-around is to visit the site with the matching domain name.

In case of (3), a common reason for this is a self-signed certificate. This is like vouching for yourself, and obviously isn't very trustworthy. It's also possible you simply don't trust the valid CA (Certificate Authority) that signed the certificate. There's a few ways to deal with this:

• Have the web service get a new certificate from a trusted CA (LetsEncrypt is a good choice these days, and is both automated and free)
• Update your trust roots (eg, if your system doesn't have the latest updates): Win 7/10, Windows Server
• Import the root CA certificate (see Certificate Path tab) that signed this certificate to your system and mark it as trusted.

Exception: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel

The exception in the title says that you are connecting to an endpoint with TLS encryption, and the certificate exposed by that endpoint is not trusted by you. This means that is not signed with a certificate that you have in your CA (Certificate Authority) Store. Like a self-signed certificate.

If the certificate is self signed, you can add it to your CA Store. If not, you can try to navigate the endpoint with your browser, and look for a copy of the certificate that the endpoint is presenting, to manually trust it. (Beware that by doing this if the endpoint has been already compromised you're manually trusting its certificate.)

You can also avoid this check by adding a custom certificate validation handler that always returns valid! (true). But, please be aware that doing this will expose you to man-in-the-middle attacks, as you'll loose the ability to check the endpoints authenticity.

ServicePointManager
    .ServerCertificateValidationCallback += 
    (sender, cert, chain, sslPolicyErrors) => true;

---

Related Topics