it-swarm.com.de

Vertrauensstellung für sicheren SSL / TLS-Kanal konnte nicht hergestellt werden - SOAP

Ich habe einen einfachen Webservice-Aufruf, der von einer .NET (C #) 2.0-Windows-App über den von Visual Studio generierten Webservice-Proxy für einen ebenfalls in C # (2.0) geschriebenen Webservice generiert wird. Dies funktioniert seit mehreren Jahren und wird auch an den rund ein Dutzend Stellen, an denen es ausgeführt wird, fortgesetzt.

Bei einer Neuinstallation an einem neuen Standort tritt ein Problem auf. Beim Versuch, den Webdienst aufzurufen, schlägt die folgende Meldung fehl:

Es konnte keine Vertrauensstellung für den sicheren SSL/TLS-Kanal hergestellt werden

Die URL des Webdienstes verwendet SSL (https: //) - dies funktioniert jedoch schon lange (und wird auch weiterhin) von vielen anderen Standorten aus.

Wo schaue ich Könnte dies ein Sicherheitsproblem zwischen Windows und .NET sein, das nur bei dieser Installation auftritt? Wenn ja, wo richte ich Vertrauensbeziehungen ein? Ich bin verloren!

309
Rob Schripsema

Gedanken (basierend auf Schmerzen in der Vergangenheit):

  • haben Sie DNS und Sichtverbindung zum Server?
  • verwenden Sie den richtigen Namen aus dem Zertifikat?
  • ist das zertifikat noch gültig
  • ist ein schlecht konfigurierter Load Balancer durcheinander?
  • macht das neue server Auf dem Computer ist die Uhr korrekt eingestellt (d. h. die UTC-Zeit ist korrekt [lokale Zeit ignorieren, sie ist weitgehend irrelevant]).
  • gibt es ein Problem mit der Zertifikatvertrauenskette? Wenn Sie vom Server zum Soap-Service navigieren, erhalten Sie SSL?
  • im Zusammenhang mit dem oben genannten - Wurde das Zertifikat an der richtigen Stelle installiert? (Möglicherweise benötigen Sie eine Kopie in Trusted Root Certification Authorities.)
  • ist der Proxy auf Computerebene des Servers richtig eingestellt? (was sich vom Proxy des Benutzers unterscheidet); Siehe proxycfg für XP/2003 (bei Vista usw. nicht sicher)
158
Marc Gravell

Die folgenden Codefragmente beheben den Fall, dass mit dem SSL-Zertifikat auf dem Server, den Sie anrufen, etwas nicht stimmt. Beispielsweise kann es selbstsigniert sein oder der Hostname zwischen dem Zertifikat und dem Server stimmt möglicherweise nicht überein.

Dies ist gefährlich wenn Sie einen Server außerhalb Ihrer direkten Kontrolle anrufen, da Sie nicht mehr so ​​sicher sein können, dass Sie mit dem Server sprechen, mit dem Sie sich verbunden fühlen. Wenn Sie jedoch mit internen Servern zu tun haben und es nicht praktikabel ist, ein "korrektes" Zertifikat zu erhalten, teilen Sie dem Webdienst Folgendes mit, um die Zertifikatsprobleme zu ignorieren, und weisen Sie ihn mutig an.

Die ersten beiden verwenden Lambda-Ausdrücke, der dritte regulären Code. Der erste akzeptiert jedes Zertifikat. Die letzten beiden prüfen mindestens, ob der Hostname im Zertifikat der erwartete ist.
... hoffe, Sie finden es hilfreich

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

// trust sender
System.Net.ServicePointManager.ServerCertificateValidationCallback
                = ((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 = cert.Subject.Contains("YourServerName");
    return result;
}
349

Die sehr einfache "catch all" -Lösung lautet:

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

Die Lösung von Sebastian-Castaldi ist etwas detaillierter.

165
Remy

Ich persönlich mag die folgende Lösung am meisten:

using System.Security.Cryptography.X509Certificates;
using System.Net.Security;

... bevor Sie den Fehler anfordern, gehen Sie wie folgt vor

System.Net.ServicePointManager.ServerCertificateValidationCallback = delegate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors) { return true; };

Fand dies nach Rücksprache Lukes Lösung

33
cusman

Wenn Sie Windows 2003 verwenden, können Sie Folgendes versuchen:

Öffnen Sie die Microsoft Management Console (Start -> Ausführen -> mmc.exe).

Wählen Sie Datei -> Snap-In hinzufügen/entfernen.

Wählen Sie auf der Registerkarte Standalone die Option Hinzufügen.

Wählen Sie das Zertifikat-Snap-In aus und klicken Sie auf Hinzufügen.

Wählen Sie im Assistenten das Computerkonto und dann Lokaler Computer. Klicken Sie auf Fertig stellen, um den Assistenten zu beenden.

Schließen Sie das Dialogfeld "Snap-In hinzufügen/entfernen".

Navigieren Sie zu Zertifikate (Lokaler Computer) und wählen Sie einen Speicher zum Importieren aus:

Wenn Sie das Stammzertifizierungsstellenzertifikat für das Unternehmen haben, das das Zertifikat ausgestellt hat, wählen Sie Vertrauenswürdige Stammzertifizierungsstellen.

Wenn Sie das Zertifikat für den Server selbst haben, wählen Sie Andere Personen

Klicken Sie mit der rechten Maustaste auf den Speicher und wählen Sie Alle Aufgaben -> Importieren

Folgen Sie dem Assistenten und geben Sie die Zertifikatsdatei an, die Sie haben.

Starten Sie danach einfach IIS neu und versuchen Sie, den Webdienst erneut aufzurufen.

Referenz: http://www.outsystems.com/NetworkForums/ViewTopic.aspx?Topic=Web-Services:-Could-not-stablish-trust-relationship-for-the-SSL/TLS- ...

18
Diogo

Wenn Sie nicht jedem blind vertrauen und nur für bestimmte Hosts eine Vertrauensausnahme vornehmen möchten, ist die folgende Lösung besser geeignet.

public static class Ssl
{
    private static readonly string[] TrustedHosts = new[] {
      "Host1.domain.com", 
      "Host2.domain.com"
    };

    public static void EnableTrustedHosts()
    {
      ServicePointManager.ServerCertificateValidationCallback = 
      (sender, certificate, chain, errors) =>
      {
        if (errors == SslPolicyErrors.None)
        {
          return true;
        }

        var request = sender as HttpWebRequest;
        if (request != null)
        {
          return TrustedHosts.Contains(request.RequestUri.Host);
        }

        return false;
      };
    }
}

Rufen Sie dann einfach Ssl.EnableTrustedHosts auf, wenn Ihre App gestartet wird.

16
Gregor Slavec

Microsoft SSL Diagnostics Tool kann möglicherweise helfen, das Problem zu identifizieren.

UPDATE der link wurde nun behoben.

7
sipwiz

Luke hat einen ziemlich guten Artikel darüber geschrieben. Ganz einfach. Probieren Sie es aus

Lukes Lösung

Grund (Zitat aus seinem Artikel (ohne Fluch)) ".. Das Problem mit dem obigen Code ist, dass es nicht funktioniert, wenn Ihr Zertifikat ungültig ist. Warum sollte ich auf eine Webseite mit einem ungültigen SSL-Zertifikat posten? Weil Ich bin billig und ich hatte keine Lust, Verisign oder eines der anderen ** - * s für ein Zertifikat an meine Testbox zu bezahlen, damit ich Ich habe es selbst unterschrieben.

System.Net.WebException Die zugrunde liegende Verbindung wurde geschlossen. Es konnte keine Vertrauensstellung zum Remoteserver hergestellt werden.

Ich weiß nichts über Sie, aber für mich sah diese Ausnahme so aus, als würde sie durch einen dummen Fehler in meinem Code verursacht, der zum Fehlschlagen von POST führte. Also suchte ich weiter und optimierte und machte alle möglichen seltsamen Dinge. Erst nachdem ich die verdammte Sache gegoogelt hatte, stellte ich fest, dass das Standardverhalten nach dem Auftreten eines ungültigen SSL-Zertifikats darin besteht, genau diese Ausnahme auszulösen. .. "

6
Hans

Ich hatte ein ähnliches Problem in der App .NET im Internet Explorer.

Ich habe das Problem beim Hinzufügen des Zertifikats (in meinem Fall VeriSign Class 3-Zertifikat) zu vertrauenswürdigen Editorzertifikaten behoben.

Go to Internet Options-> Content -> Publishers and import it

Sie können das Zertifikat erhalten, wenn Sie es exportieren von:

Internet Options-> Content -> Certificates -> Intermediate Certification Authorities -> VeriSign Class 3 Public Primary Certification Authority - G5

vielen Dank

3
debiasej

Ich bin gerade auf dieses Problem gestoßen. Meine Lösung bestand darin, die Systemzeit durch manuelles Synchronisieren mit den Zeitservern zu aktualisieren. Dazu können Sie:

  • Klicken Sie mit der rechten Maustaste auf die Uhr in der Taskleiste
  • Wählen Sie Adjust Date/Time
  • Wählen Sie die Registerkarte Internet Time
  • Klicken Sie auf Change Settings
  • Wählen Sie Update Now

In meinem Fall wurde die Synchronisierung nicht korrekt durchgeführt, sodass ich mehrmals darauf klicken musste, bevor die Aktualisierung korrekt durchgeführt werden konnte. Wenn es weiterhin fehlerhaft aktualisiert wird, können Sie sogar versuchen, einen anderen Zeitserver als die Server-Dropdown-Liste zu verwenden.

Versuche dies:

System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;

Beachten Sie, dass Sie mindestens mit 4.5 .NET Framework arbeiten müssen

2
Manuel Roldan

Für diejenigen, die dieses Problem über einen VS-Client haben, der einmal erfolgreich eine Dienstreferenz hinzugefügt und versucht hat, den ersten Aufruf auszuführen, wurde diese Ausnahme gemeldet: "Die zugrunde liegende Verbindung wurde geschlossen: Konnte keine Vertrauensbeziehung für den sicheren SSL/TLS-Kanal herstellen." Wenn Sie (wie in meinem Fall) eine Endpunkt-URL mit der IP-Adresse verwenden und diese Ausnahme erhalten haben, sollten Sie die Dienstreferenz wahrscheinlich erneut hinzufügen müssen, indem Sie die folgenden Schritte ausführen:

  • Öffnen Sie die Endpunkt-URL in Internet Explorer.
  • Klicken Sie auf den Zertifikatfehler (rotes Symbol in der Adressleiste)
  • Klicken Sie auf Zertifikate anzeigen.
  • Nehmen Sie den ausgegebenen Namen "name" und ersetzen Sie die IP-Adresse oder den von uns verwendeten Namen und erhalten Sie den Fehler für diesen "Namen".

Versuch es noch einmal :). Vielen Dank

1
Ernest

Ich hatte diesen Fehler auf einem Webserver mit folgender URL:

a.b.domain.com

aber es gab kein Zertifikat dafür, also bekam ich einen DNS-Namen

a_b.domain.com

Ich habe hier nur einen Hinweis auf diese Lösung gegeben, da dies in Google ganz oben stand.

1
Thomas Koelle

In meinem Fall habe ich versucht, SSL in meiner Visual Studio-Umgebung mit IIS 7 zu testen.

Folgendes habe ich letztendlich getan, um es zum Laufen zu bringen:

  • Unter meiner Site im Abschnitt "Bindungen" rechts in IIS musste ich die "https" -Bindung zu Port 443 hinzufügen und "IIS Express-Entwicklungszertifikat" auswählen.

  • Unter meiner Site im Abschnitt 'Erweiterte Einstellungen ...' auf der rechten Seite musste ich die 'Aktivierten Protokolle' von "http" in "https" ändern.

  • Unter dem Symbol "SSL-Einstellungen" habe ich "Akzeptieren" für Client-Zertifikate ausgewählt.

  • Dann musste ich den App-Pool recyceln.

  • Ich musste auch das lokale Host-Zertifikat mit mmc.exe in meinen persönlichen Speicher importieren.

Meine web.config -Datei wurde bereits richtig konfiguriert, und nachdem ich alle oben genannten Punkte geklärt hatte, konnte ich meine Tests fortsetzen.

0
Popo

Meine Lösung (VB.Net, die "Staging" -Version (UAT) dieser Anwendung muss mit dem "Staging" -Zertifikat funktionieren, wirkt sich jedoch nicht auf Anforderungen aus, sobald sie sich auf der Live-Site befinden.):

    ...
        Dim url As String = ConfigurationManager.AppSettings("APIURL") & "token"
        If url.ToLower().Contains("staging") Then
           System.Net.ServicePointManager.ServerCertificateValidationCallback = AddressOf AcceptAllCertifications
        End If
    ...

    Private  Function AcceptAllCertifications(ByVal sender As Object, ByVal certification As System.Security.Cryptography.X509Certificates.X509Certificate, ByVal chain As System.Security.Cryptography.X509Certificates.X509Chain, ByVal sslPolicyErrors As System.Net.Security.SslPolicyErrors) As Boolean
        Return True
    End Function
0
GreenRock