it-swarm.com.de

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

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

Ich habe einen WCF-Dienst, der in IIS 7 mit HTTPS gehostet wird. Wenn ich in Internet Explorer zu dieser Site navigiere, funktioniert das wie ein Zauber, weil ich habe hinzugefügt habe das Zertifikat an den lokalen Stammzertifizierungsstellenspeicher.

Ich entwickle auf 1 Rechner, also sind Client und Server derselbe Rechner. Das Zertifikat wird direkt vom IIS 7-Verwaltungs-Snap-In selbst signiert.

Ich bekomme jetzt ständig diesen Fehler ...

Konnte keine Vertrauensstellung für den sicheren SSL/TLS-Kanal mit Berechtigung herstellen.

... wenn von der Client-Konsole aufgerufen.

Ich habe mir manuell Berechtigungen und Netzwerkdienste für das Zertifikat gegeben, indem ich findprivatekey und cacls.exe.

Ich habe versucht, über SOAPUI eine Verbindung zum Dienst herzustellen, und das funktioniert. Daher muss dies ein Problem in meiner Clientanwendung sein, bei der es sich um Code handelt, der auf dem Code basiert, der für die Arbeit mit http verwendet wurde.

Wo kann ich noch suchen? Ich habe anscheinend alle Möglichkeiten ausgeschöpft, warum ich keine Verbindung herstellen kann.

127
JL.

Um dieses Problem zu umgehen, können Sie dem ServicePointManager des ServerCertificateValidationCallback auf der Clientseite einen Handler hinzufügen:

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

beachten Sie jedoch, dass dies keine gute Vorgehensweise ist , da das Serverzertifikat vollständig ignoriert wird und der Service Point Manager darüber informiert wird Was auch immer für ein Zertifikat in Ordnung ist, das die Client-Sicherheit ernsthaft gefährden kann. Sie können dies verfeinern und einige benutzerdefinierte Überprüfungen durchführen (für Zertifikatnamen, Hash usw.). Zumindest können Sie Probleme während der Entwicklung umgehen, wenn Sie Testzertifikate verwenden.

187

Wenn ich dieses Problem habe, hat die client.config folgende Endpunkte:

 https://myserver/myservice.svc 

aber das Zertifikat erwartete

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

Das Ändern der Endpunkte entsprechend dem FQDN des Servers behebt mein Problem. Ich weiß, dass dies nicht die einzige Ursache für dieses Problem ist.

37
Mike Cheel

die ersten beiden verwenden Lambda, die dritten regulären Code ... ich 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 = false;
        if (cert.Subject.ToUpper().Contains("YourServerName"))
        {
            result = true;
        }

        return result;
    }
19

Ihr Problem tritt auf, weil Sie einen selbstsignierten Schlüssel verwenden. Der Client vertraut weder diesem Schlüssel, noch stellt der Schlüssel selbst eine Kette zur Validierung oder eine Zertifikatswiderrufsliste bereit.

Sie haben ein paar Möglichkeiten - Sie können

  1. zertifikatsüberprüfung auf dem Client deaktivieren (fehlerhafter Zug, Angriffe von Mann in der Mitte sind im Überfluss)

  2. verwenden Sie makecert, um eine Stammzertifizierungsstelle zu erstellen und Zertifikate daraus zu erstellen (in Ordnung, aber es gibt immer noch keine CRL).

  3. erstellen Sie eine interne Stammzertifizierungsstelle mit Windows Certificate Server oder einer anderen PKI-Lösung, und vertrauen Sie dann diesem Stammzertifikat.

  4. kauf eines SSL-Zertifikats von einer der vertrauenswürdigen Zertifizierungsstellen (teuer)

19
blowdart

Eine einzeilige Lösung. Fügen Sie dies an einer beliebigen Stelle hinzu, bevor Sie den Server auf der Clientseite anrufen:

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

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

14
Gaspa79

Ich bin auf dasselbe Problem gestoßen und konnte es mit zwei Lösungen lösen: Zuerst habe ich das MMC "Zertifikate" -Snap-In für das "Computerkonto" verwendet und das selbstsignierte Zertifikat gezogen Dies bedeutet, dass der lokale Computer (derjenige, der das Zertifikat generiert hat) diesem Zertifikat nun vertraut. Zweitens ist mir aufgefallen, dass das Zertifikat für einen internen Computernamen generiert wurde, aber auf den Webdienst zugegriffen wurde Die Verwendung eines anderen Namens führte zu einer Nichtübereinstimmung bei der Überprüfung des Zertifikats. Wir haben das Zertifikat für computer.operations.local generiert, aber mit https://computer.internaldomain.companydomain.com auf den Webdienst zugegriffen Wir haben die URL auf die zur Erstellung des Zertifikats verwendete URL umgestellt. Wir haben keine Fehler mehr erhalten.

Möglicherweise hätte es funktioniert, nur die URLs zu wechseln, aber wenn Sie das Zertifikat als vertrauenswürdig eingestuft haben, vermeiden Sie auch den roten Bildschirm in Internet Explorer, auf dem angegeben wird, dass das Zertifikat nicht als vertrauenswürdig eingestuft wird.

9

Bitte führen Sie folgende Schritte durch:

  1. Öffnen Sie den Service Link im IE.

  2. Klicken Sie in der Adressleiste auf die Erwähnung Zertifikatfehler und dann auf Zertifikate anzeigen.

  3. Scheck ausgestellt auf: Name.

  4. Nehmen Sie den ausgegebenen Namen und ersetzen Sie localhost im Namen der Dienst- und Client-Endpunkt-Basisadresse durch einen vollqualifizierten Domänennamen (FQDN).

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

7
Rahul Rai

Wenn Sie .NET Core verwenden, versuchen Sie Folgendes:

client.ClientCredentials.ServiceCertificate.SslCertificateAuthentication =
        new X509ServiceCertificateAuthentication()
        {
            CertificateValidationMode = X509CertificateValidationMode.None,
            RevocationMode = System.Security.Cryptography.X509Certificates.X509RevocationMode.NoCheck
        };
5
Grzegorz J

Zusätzlich zu den obigen Antworten kann dieser Fehler auftreten, wenn auf Ihrem Client die falsche TLS-Version ausgeführt wird, z. B. wenn auf dem Server nur TLS 1.2 ausgeführt wird.

Sie können das Problem beheben, indem Sie Folgendes verwenden:

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

Ich hatte das gleiche problem Ich hatte auch CA-Zertifikate im lokalen Speicher hinzugefügt, aber ich tat auf die falsche Weise.

Mit der mmc-Konsole (Start -> Ausführen -> mmc) sollten Sie Zertifikate Snap-In als Dienstkonto (Auswahl des Dienstkontos von IIS) oder Computerkonto (es wird hinzugefügt) hinzufügen für jedes Konto auf der Maschine)

Hier ein Bild von dem, wovon ich rede Add snap-in for a service account or the computer account

Von hier aus können Sie Zertifikate von Zertifizierungsstellen (Trusted Root CAs und Intermediate CAs) hinzufügen, und alles funktioniert einwandfrei

4
dar0x

Ich hatte ein ähnliches Problem mit dem selbstsignierten Zertifikat. Ich könnte es lösen, indem ich den gleichen Zertifikatsnamen wie den FQDN des Servers verwende.

Im Idealfall sollte der SSL-Teil auf der Serverseite verwaltet werden. Der Client muss kein Zertifikat für SSL installieren. Einige der erwähnten Posts behandeln auch das Umgehen von SSL aus dem Client-Code. Aber damit bin ich überhaupt nicht einverstanden.

4
Umesh Bhavsar

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

Oh. Und ich habe zuerst Folgendes über eine Administrator-Eingabeaufforderung hinzugefügt:

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

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

Sie können alle vorhandenen URLs anzeigen, indem Sie den folgenden Befehl eingeben: netsh http show urlacl

3
Haguna

Habe gerade ein ähnliches Problem behoben.

Ich stellte fest, dass ich einen Anwendungspool hatte, der unter einem Konto ausgeführt wurde, das nur über die Leseberechtigung für das verwendete Zertifikat verfügte.

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

Zertifikatsberechtigungen können über MMC-Konsole verwaltet werden

0
Alberto

Dies trat auf, wenn versucht wurde, eine Verbindung zum WCF-Dienst nur unter Verwendung des Hostnamens herzustellen, z. https: //Host/MyService.svc bei Verwendung eines Zertifikats, das an einen Namen gebunden ist, z. Host.mysite.com.

Wechseln Sie zu https://Host.mysite.com/MyService.svc und dies hat es gelöst.

0
sonia

Dies ist beim Versuch aufgetreten, eine Verbindung zum WCF-Dienst über herzustellen. die IP, z.B. https://111.11.111.1:port/MyService.svc während Sie ein Zertifikat verwenden, das an einen Namen gebunden ist, z. mysite.com.

Wechseln zum https://mysite.com:port/MyService.svc es gelöst.

0
lko