WebException konnte keine Vertrauensstellung für die SSL etablieren / TLS sicheren Kanal

Question

hat mein Unternehmen einen .NET Web-Service und einen Client-DLL entwickelt, dass Anwendungen, den Web-Service. Der Webservice ist auf unserem Server über ssl gehostet und das CERT wird zur Verfügung gestellt und unterzeichnet von GoDaddy. Wir haben einige Kunden in einer gehosteten Umgebung, die folgende Fehlermeldung von dem Client-DLL bekommen, wenn es versucht, unseren Web-Service zugreifen zu können.

System.Net.WebException Die zugrunde liegende Verbindung wurde geschlossen. Konnte keine Vertrauensstellung für den sicheren SSL / TLS-Kanal einzurichten

Unsere fix war sie öffnen IE auf dem Server zu haben, die eine Herausforderung in und von sich selbst für viele der gehosteten Dienste, und auf die WSDL-URL gehen. IE fordert dann sich mit einem Sicherheitsalarm-Dialog. Er sagt, das cert Datum gültig ist und ein gültiger Name den Namen der Seite übereinstimmt, sondern wurde von einer Firma ausgestellt, die Sie nicht vertraut gewählt haben. Wenn sie auf Ja, um fortzufahren, kann der Client-DLL dann eine Verbindung erfolgreich an den Webservice und arbeiten normal weiter.

Hat jemand eine Idee, warum GoDaddy wäre da nicht gültig Verlage Liste gewesen sein? Alle Server haben wir ausgeführt hat GoDaddy als gültige Autorität. Ich vermute, aus Gründen der Sicherheit, sie die Autorität für GoDaddy deinstalliert haben, aber nicht völlig davon überzeugt, dass es nicht ein anderes zugrunde liegendes Problem.

Leider habe ich nicht hatte viel Glück versuchen, dies vor Ort zu erstellen. Wenn ich in Internetoptionen gehen und die GoDaddy Behörden entfernen und treffen unseren Service arbeitet ssl gut. Ich gehe zurück in die Liste der Verlage und GoDaddy wird gleich wieder setzen in. So ist meine zweite Frage ist, Wie zum Teufel halten Sie von GoDaddy loszuwerden, damit ich eine ungültige cert Warnung erhalten kann?

Okay, letzte Frage. Gibt es eine Möglichkeit in Code, den ich den Webservice sagen kann, um ungültige Zertifikate zu ignorieren. Ich habe einige Beiträge zu sehen dies programmatisch mit WCF auf zu tun, aber nicht alt Web-Service.

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.

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

Answer 3

VB.NET equivalent is

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

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.

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.