Lösung "Konnte Vertrauensbeziehung für den sicheren SSL/TLS-Kanal mit Autorität nicht herstellen"

Question

Ich dachte wirklich, ich hätte dieses Problem behoben, aber es wurde nur vorher getarnt.

Ich habe einen WCF-Dienst in IIS 7 mit HTTPS gehostet. Wenn ich zu dieser Site in Internet Explorer blättern, funktioniert es wie ein Charme, weil ich das das Zertifikat dem lokalen Stammzertifikatsautoritätsspeicher hinzugefügt habe.

Ich bin auf 1 Maschine entwickeln, so Client und Server sind die gleiche Maschine. Das Zertifikat ist selbst unterzeichnet direkt von IIS 7 Management-Snap in.

ich immer wieder diesen Fehler jetzt ...

kann keine Vertrauensstellung für den sicheren SSL/TLS-Kanal mit Behörde ein.

... wenn von der Client-Konsole aus aufgerufen.

Ich gab mir manuell Berechtigungen und Netzwerk-Service für das Zertifikat, mit findprivatekey und cacls.exe.

Ich habe versucht, eine Verbindung mit dem Dienst mit SOAPUI, und das funktioniert, so muss es ein Problem in meiner Client-Anwendung sein, die Code basiert auf, was früher mit http arbeitete.

Wo sonst kann ich aussehen Ich habe alle Möglichkeiten ausgeschöpft, warum ich keine Verbindung herstellen kann?

Answer 1

Als Abhilfe können Sie ServerCertificateValidationCallback auf der Client-Seite einen Handler die ServicePointManager ‚s könnte hinzufügen:

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

aber bewusst sein, dass dies ist keine gute Praxis wie es vollständig den Server ignoriert Zertifikat und teilt dem Servicepunkt-Manager mit, dass ein beliebiges Zertifikat in Ordnung ist, das die Client-Sicherheit ernsthaft gefährden kann. Sie könnten dies verfeinern und einige benutzerdefinierte Prüfungen durchführen (für Zertifikatsnamen, Hash usw.). können Sie Probleme bei der Entwicklung umgehen, wenn Sie Testzertifikate verwenden.

Answer 2

Ihr Problem tritt auf, weil Sie einen selbstsignierten Schlüssel verwenden. Der Client vertraut diesem Schlüssel nicht, noch stellt der Schlüssel selbst eine zu validierende Kette oder eine Zertifikatsperrliste bereit.

Sie haben ein paar Optionen - Sie auf der Client (schlechter Zug, ein Mann in den Middle-Angriffe gibt es zuhauf)

Verwendung makecert

1. Abschaltzeit Zertifikatsüberprüfung kann eine Wurzel erstellen CA und Zertifikate erstellen (OK Verschieben, aber es gibt immer noch keine CRL)

2. Erstellen Sie eine interne Stamm-CA mit Vertrauen Windows Certificate Server oder andere PKI-Lösung dann diese Wurzel cert (ein bisschen wie ein Schmerz zu verwalten)

3. Kauf ein SSL-Zertifikat von einer der vertrauenswürdigen Zertifizierungsstellen (teuer)

Answer 3

Fügen sie diese auf Ihren Client-Code

:

ServicePointManager.ServerCertificateValidationCallback = new RemoteCertificateValidationCallback(
    delegate 
    { 
     return true; 
    }); 

Answer 4

traf ich das gleiche Problem, und ich war in der Lage, es zu lösen mit zwei Lösungen: F Zuerst verwendete ich das MMC-Snap-In "Zertifikate" für das "Computerkonto" und zog das selbstsignierte Zertifikat in den Ordner "Vertrauenswürdige Stammzertifizierungsstellen". Dies bedeutet, dass der lokale Computer (derjenige, der das Zertifikat generiert hat) nun diesem Zertifikat vertraut. Zweitens bemerkte ich, dass das Zertifikat für einen internen Computernamen generiert wurde, aber auf den Webdienst wurde mit einem anderen Namen zugegriffen. Dies führte zu einer Nichtübereinstimmung bei der Validierung des Zertifikats. Wir haben das Zertifikat für computer.operations.local generiert, aber mit https://computer.internaldomain.companydomain.com auf den Web-Service zugegriffen. Als wir die URL auf die zum Generieren des Zertifikats verwendete URL umgestellt haben, sind keine Fehler mehr aufgetreten.

Vielleicht hätte nur das Umschalten von URLs funktioniert, aber indem Sie das Zertifikat vertrauenswürdig machen, vermeiden Sie auch den roten Bildschirm in Internet Explorer, wo es Ihnen sagt, dass es dem Zertifikat nicht vertraut.

Answer 5

Ich hatte ähnliches Problem mit selbstsignierten Zertifikat. Ich könnte es auflösen, indem ich den Zertifikatsnamen wie FQDN des Servers benutze.

Im Idealfall sollte SSL-Teil auf der Serverseite verwaltet werden. Der Client muss kein Zertifikat für SSL installieren. Auch einige der erwähnten Posts über das Umgehen des SSL vom Client-Code. Aber ich stimme überhaupt nicht damit überein.

Answer 6

das beide erste Einsatz Lambda, verwendet die dritte regelmäßigen Code ... hoffen, dass Sie es nützlich finden

  //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 = false; 
     if (cert.Subject.ToUpper().Contains("YourServerName")) 
     { 
      result = true; 
     } 

     return result; 
    } 

Answer 7

Wenn ich dieses Problem ist es, weil die client.config wie seine Endpunkte hatte:

https://myserver/myservice.svc 

aber das Zertifikat erwartete

https://myserver.mydomain.com/myservice.svc 

die Endpunkte ändern übereinstimmen Der FQDN des Servers behebt mein Problem. Ich weiß, dass dies nicht die einzige Ursache für dieses Problem ist.

Answer 8

Ich habe gerade das Zertifikat in den Ordner "Trusted Root Certification Authorities" gezogen und voila hat alles gut funktioniert.

Oh. Und fügte ich zuerst die folgenden von einem Prompt Administrator Befehl:

netsh http add urlacl url=https://+:8732/Servicename user=NT-MYNDIGHET\INTERAKTIV 

Ich bin nicht sicher, ob der Name, den Sie für den Benutzer benötigen (bei mir ist norwegisch wie Sie sehen können!): user=NT-AUTHORITY/INTERACTIVE?

Sie können alle vorhandenen urlacl sehen, mit dem folgenden Befehl: netsh http show urlacl

Answer 9

Dies geschah, wenn sie über an den WCF-Dienst zu verbinden versucht. die IP z.B. https://111.11.111.1:port/MyService.svc, während ein Zertifikat verwendet wird, das an einen Namen gebunden ist, z. mysite.com.

Die Umstellung auf die https://mysite.com:port/MyService.svc löste es.

Answer 10

Bitte wie folgt vorgehen:

1. öffnen Service-Link im Internet Explorer.

2. Klicken Sie auf die in der Adressleiste angegebene Fehlermeldung und klicken Sie auf Zertifikate anzeigen.

3. Überprüfung ausgestellt auf: Name.

4. Nehmen Sie den erteilten Namen und ersetzen Sie localhost Erwähnung in Service und Client-Endpunkt Basisadresse mit einem voll qualifizierten Domänennamen (FQDN).

Beispiel: https: // localhost : 203/SampleService.svc zu https: // INL-126166-.groupinfra.com: 203/SampleService.svc

Answer 11

I hatte das gleiche Problem. Ich hatte auch CA-Zertifikate im lokalen Laden hinzugefügt, aber ich habe auf die falsche Art und Weise getan.

Mit mmc-Konsole (Start -> Ausführen ->mmc) sollten Sie Zertifikate hinzufügen Snap-In als Service-Konto (das Dienstkonto von IIS Wahl) oder Computer-Konto (es fügt für jedes Konto auf der Maschine

)

hier ein Bild von dem, was ich rede

von hier jetzt können Sie Zertifikate von CAs (Vertrauenswürdige Stammzertifizierungsstellen und Intermediate CAs) hinzufügen und e Alles wird gut funktionieren

Answer 12

Dies ist beim Versuch aufgetreten, eine Verbindung zum WCF-Dienst herzustellen, indem nur der Hostname z. https://host/MyService.svc, während ein Zertifikat verwendet wird, das an einen Namen gebunden ist, z. host.mysite.com.

Umschalten auf die und dies hat es gelöst.

Answer 13

Eine Ein-Zeilen-Lösung.Fügen Sie diese überall, bevor der Server auf der Client-Seite aufrufen:

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

Dies sollte nur zu Testzwecken verwendet werden, da der Client SSL/TLS-Sicherheitsüberprüfungen überspringen.

Answer 14

Zusätzlich zu den obigen Antworten kann dieser Fehler auftreten, wenn Ihr Client die falsche TLS-Version ausführt, z. B. wenn der Server nur TLS 1.2 ausführt.

Sie können das Problem beheben, indem Sie:

  ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; //tested in .NET 4.5 

Answer 15

fixiert Nur ein ähnliches Problem.

Ich erkannte, dass ich einen Anwendungspool hatte, der unter einem Konto ausgeführt wurde, das nur Leseberechtigung über das Zertifikat hatte, das es verwendet wurde.

Die .NET-Anwendung konnte das Zertifikat korrekt abrufen, aber diese Ausnahme wurde nur ausgelöst, wenn GetRequestStream() aufgerufen wurde.

Zertifikate Berechtigungen können über MMC console