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

Question

My company has developed a .NET web service and a client dll that uses that web service. The webservice is hosted on our server over ssl and the cert is provided and signed by GoDaddy. We have some clients in a hosted environment that are getting the following error message from the client dll when it tries to access our web service.

System.Net.WebException The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

Our fix has been to have them open IE on the server, which is a challenge in and of itself for a lot of the hosted services, and go to the WSDL url. IE then prompts them with a security alert dialog. It says the cert date is valid and a valid name matching the name of the page, but was issued by a company you have not chosen to trust. When they click Yes to proceed, the client dll can then succesfully connect to the web service and operate as normal.

Does anyone have any idea why GoDaddy would not have been in there valid publishers list? All of the servers we have running has GoDaddy as a valid authority. I'm guessing, for security reasons, they've uninstalled the authority for GoDaddy, but not totally convinced that there's not some other underlying issue.

Unfortunately, I haven't had much luck trying to recreate this locally. If I go into Internet Options and remove the GoDaddy authorities and hit our service, ssl works just fine. I go back into the list of publishers and GoDaddy gets put right back in. So my second question is, How the heck do you get rid of GoDaddy so I can get an invalid cert warning?

Okay, last question. Is there a way in code I can tell the web service to ignore invalid certs. I've seen some posts on doing this programatically with WCF but not old web services.

Radiotelegraph

is your DNS resolving exactly as required by the secure cert? ie: https://wsdl.companydomain.local or whatever is specified in the SSL cert. – Juback

I believe so. I validated our cert here, sslshopper.com/ssl-checker.html, and everything checked out fine. – Radiotelegraph

You're asking too many questions at one time. The trusted root certificates list on the local machine and on the server machine is a carefully guarded resource and is not updated often. Anybody can create new root certificates. GoDaddy may have created additional root certs that are not in the Microsoft distribution list, and your SSL cert is signed by one of them. It's also possible the root cert used to sign your SSL cert has been compromised and placed on a "do not trust" list, which means your SSL certs are not trustworthy. – Durazzo

Thanks everyone. We've decided to use a more trusted authority. Also noted, I will focus my questions and move questions like this to ServerFault. – Radiotelegraph

Answer 1

You may need to install on your servers the intermediate certificates used to sign your SSL certs.

Browsers will attempt to validate the SSL certificate by checking the validation of the chain of certs that signed the SSL cert. If the server doesn't supply the certificate chain with the SSL certificate, the browser may reject the SSL cert. (More of an issue for Firefox than IE). The root certificate must still be installed on the client machine for any of this to work.

Durazzo

I'm not saying you're wrong, but it seems that the browser shouldn't ask the server for it's root cert list... That seems like a huge security hole. Also, it sounds like the machines in question don't trust GoDaddy as a CA. This means that the browser doesn't have GoDaddy listed in it's list of trusted root authorities. The only way to get there is via a microsoft update OR manually trusting it. – Solitaire

@Chris: A common problem in SSL installations is that the server returns only the leaf node cert with no indication of the certificate chain. IE browser often will accept such certs, but Firefox will not. The solution to appease Firefox is to make sure your intermediate certs are available on the server. You're probably right about the root cert - I've edited the answer. – Durazzo

Answer 2

I fixed this error by adding this line before calling the web method:

System.Net.ServicePointManager.ServerCertificateValidationCallback = (senderX, certificate, chain, sslPolicyErrors) => { return true; };

Caulis

Even though this is not the ideal solution, if you are using an invalid ssl (which could be unavoidable in certain cases), this could be an acceptable workaround, give you understand what you are doing. – Oleo

This cannot be a solution unless you add custom logic to validate your cert. You cannot just accept any cert in prod. There is no point in using SSL/TLS if you ignore cert validation and accept any cert instead. – Contravallation

Agree with Maks comment about not doing this in prod but this solution saved me time for an internal-use-only utility I'm working with. Just be careful. – Genagenappe

If you wrap it with #if DEBUG #endif - should work properly and you won't commit it to prod accidentally. – Bukovina

It's better to create a method instead of a lambda and use ServicePointManager.ServerCertificateValidationCallback += MyCallbackMethod; PLEASE remember to Unsubscribe when you've received your TLS result with ServicePointManager.ServerCertificateValidationCallback -= MyCallbackMethod; Failure to do so will leave ALL TLS web requests using your callback! You can also inspect the cert and chain for minimal Issuer/Thumbprint/NotAfter text and date expectations. – Pennant

Answer 3

VB.NET equivalent is

   System.Net.ServicePointManager.ServerCertificateValidationCallback = Function(senderX, certificate, chain, sslPolicyErrors)
                                                                             Return True
                                                                         End Function

Benue

Answer 4

This is really more of a serverfault question, but I'll add what I can here.

The root cert authority list that windows machines normally trust is updated fairly regularly. This comes down as a windows update to IE. You can see MSDN for more information.

If your clients do not have windows update turned on or are actively ignoring windows updates, which is unfortunately very common for a lot of IT departments, then there's not much you can do other than switch SSL providers.

Basically, they need to get the certificate updates or you need to switch to a cert provider that has a high probability of already being trusted by the machines in question. Typically this means Verisign or Thawte. The third alternative is the route you've been going down: have them manually trust the root CA.

At the end of the day I hate the idea of changing an app in this way simply because the IT departments in question are morons but the real question boils down to how your company wants to handle this.

Solitaire

Answer 5

When you look at the Go Daddy Certification Path of that certificate on the web server, do you see Go Daddy Class xxx or Starfield Class xxx ?

And from your non-legacy client i.e Windows Vista upwards, what does the Go Daddy Certification Path display? Go Daddy Class xxx or Starfield Class xxx ?

And these clients that get the warning, are they legacy clients? i.e WinXP and older?

Root Certificate updates works differently as of Windows Vista.

http://support.microsoft.com/kb/931125

Root certificates on Windows Vista and later are distributed via the automatic root update mechanism – that is, per root certificate. When a user visits a secure Web site (by using HTTPS SSL), reads a secure email (S/MIME), or downloads an ActiveX control that is signed (code signing) and encounters a new root certificate, the Windows certificate chain verification software checks Microsoft Update for the root certificate. If it finds it, it downloads the current Certificate Trust List (CTL) containing the list of all trusted root certificates in the Program, and verifies that the root certificate is listed there; it then downloads the specified root certificate to the system and installs it in the Windows Trusted Root Certification Authorities Store.

You'll probably find that your Go Daddy Certification Path on the web server thinks it's Starfield Class 2 instead of Go Daddy Class 2 so you installed the wrong root certificate. It caught me out as when you view in on the web server it doesn't display a root certificate warning, download and install the Do Daddy class 2 root cert and remove the Starfield one and your problem should dissapear.

Matherne

Answer 6

Adding to @amit's answer:

If you are ready to forego SSL validation .NET exposes a public function delegate for this:

handler.ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

Zoonosis