Problemlösung "Es konnte keine Vertrauensbeziehung für den sicheren SSL / TLS-Kanal mit Berechtigung hergestellt werden"

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

Ich habe einen WCF-Dienst, der in IIS 7 mithilfe von HTTPS gehostet wird. Wenn ich auf diese Seite in Internet Explorer durchsuchen, es funktioniert wie ein Charme, ist dies , weil ich habe das Zertifikat auf den lokalen Stammzertifizierungsstelle Speicher hinzugefügt.

Ich entwickle auf einem Computer, daher sind Client und Server derselbe Computer. Das Zertifikat ist direkt vom IIS 7-Verwaltungs-Snap-In selbstsigniert.

Ich bekomme jetzt ständig diesen Fehler ...

Es konnte keine Vertrauensbeziehung für den sicheren SSL / TLS-Kanal mit Berechtigung hergestellt werden.

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

Ich habe mir manuell Berechtigungen und Netzwerkdienste für das Zertifikat erteilt, verwendet findprivatekeyund verwendet cacls.exe.

Ich habe versucht, über SOAPUI eine Verbindung zum Dienst herzustellen, und das funktioniert. Daher muss es sich um ein Problem in meiner Clientanwendung handeln, bei dem es sich um Code handelt, der auf dem basiert, was früher mit http funktioniert hat.

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

Als Abhilfe können Sie einen Handler für das Add ServicePointManager‚s ServerCertificateValidationCallbackauf der Client - Seite:

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

Beachten Sie jedoch, dass dies keine bewährte Methode ist, da das Serverzertifikat vollständig ignoriert wird und dem Service Point Manager mitgeteilt wird, dass jedes Zertifikat in Ordnung ist, was die Client-Sicherheit ernsthaft beeinträchtigen kann. Sie können dies verfeinern und einige benutzerdefinierte Überprüfungen durchführen (für Zertifikatsnamen, Hash usw.). Zumindest können Sie Probleme während der Entwicklung umgehen, wenn Sie Testzertifikate verwenden.

Wenn ich dieses Problem habe, liegt es daran, dass die client.config ihre Endpunkte hatte wie:

 https://myserver/myservice.svc 

aber das Zertifikat erwartete

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

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

Die ersten beiden verwenden Lambda, die dritte verwendet regulären Code. Ich hoffe, Sie finden ihn 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;
    }

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

Sie haben einige Möglichkeiten - Sie können

1. Deaktivieren Sie die Zertifikatsüberprüfung auf dem Client (schlechter Zug, viele Angriffe in der Mitte gibt es zuhauf)

2. Verwenden Sie makecert, um eine Stammzertifizierungsstelle zu erstellen und daraus Zertifikate zu erstellen (ok, verschieben, aber es gibt 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 (ein bisschen mühsam zu verwalten).

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

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

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

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

Ich bin auf dasselbe Problem gestoßen und konnte es mit zwei Lösungen beheben: Erstens habe ich das MMC-Snap-In "Zertifikate" für das "Computerkonto" verwendet und das selbstsignierte Zertifikat in den Ordner "Vertrauenswürdige Stammzertifizierungsstellen" gezogen . Dies bedeutet, dass der lokale Computer (derjenige, der das Zertifikat generiert hat) diesem Zertifikat jetzt vertraut. Zweitens habe ich festgestellt, dass das Zertifikat für einen internen Computernamen generiert wurde, aber auf den Webdienst unter einem anderen Namen zugegriffen wurde. Dies führte zu einer Nichtübereinstimmung bei der Validierung des Zertifikats. Wir haben das Zertifikat für computer.operations.local generiert, aber über https://computer.internaldomain.companydomain.com auf den Webdienst zugegriffen . Als wir die URL auf die URL umstellten, mit der das Zertifikat erstellt wurde, wurden keine Fehler mehr angezeigt.

Vielleicht hätte nur das Wechseln der URLs funktioniert, aber wenn Sie das Zertifikat als vertrauenswürdig einstufen, vermeiden Sie auch den roten Bildschirm in Internet Explorer, auf dem angegeben wird, dass das Zertifikat nicht vertrauenswürdig ist.

Wenn Sie .net Core verwenden, versuchen Sie Folgendes:

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

Bitte führen Sie folgende Schritte aus:

1. Öffnen Sie den Service-Link im IE.

2. Klicken Sie auf den in der Adressleiste angegebenen Zertifikatfehler und dann auf Zertifikate anzeigen.

3. Scheck ausgestellt an: Name.

4. Nehmen Sie den ausgegebenen Namen und ersetzen Sie die Erwähnung von localhost im Dienst- und Client-Endpunkt-Basisadressnamen durch einen vollqualifizierten Domänennamen (FQDN).

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

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;

Ich hatte das gleiche Problem. Ich hatte auch CA-Zertifikate im lokalen Geschäft hinzugefügt, aber ich tat es auf die falsche Weise.

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

Hier ein Bild von dem, wovon ich spreche

Von hier aus können Sie Zertifikate von Zertifizierungsstellen ( vertrauenswürdige Stammzertifizierungsstellen und Zwischenzertifizierungsstellen ) hinzufügen , und alles funktioniert einwandfrei

Ich hatte ein ähnliches Problem mit dem selbstsignierten Zertifikat. Ich könnte es beheben, indem ich den Zertifikatsnamen verwende, der dem FQDN des Servers entspricht.

Idealerweise sollte der SSL-Teil auf der Serverseite verwaltet werden. Der Client muss kein Zertifikat für SSL installieren. In einigen der genannten Beiträge wurde auch die Umgehung von SSL aus dem Clientcode erwähnt. Aber damit bin ich überhaupt nicht einverstanden.

Ich habe das Zertifikat einfach in den Ordner "Trusted Root Certification Authorities" gezogen und voila alles hat 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

Dies trat auf, wenn versucht wurde, eine Verbindung zum WCF-Dienst über herzustellen. die IP zB https://111.11.111.1:port/MyService.svcbei Verwendung eines Zertifikats, das an einen Namen gebunden ist, zB mysite.com.

Wechsel zum https://mysite.com:port/MyService.svcgelösten Problem.

Dies trat auf, wenn versucht wurde, eine Verbindung zum WCF-Dienst herzustellen, indem nur der Hostname verwendet wurde, z. B. https: //host/MyService.svc, während ein Zertifikat verwendet wurde, das an einen Namen gebunden war, z. B. host.mysite.com.

Durch Wechseln zu https://host.mysite.com/MyService.svc wurde das Problem behoben.

Habe gerade ein ähnliches Problem behoben.

Mir wurde klar, dass ich einen Anwendungspool hatte, der unter einem Konto ausgeführt wurde, das nur Leseberechtigung für das verwendete Zertifikat hatte.

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

Zertifikatsberechtigungen können über die MMC-Konsole verwaltet werden

Wenn Sie den .net-Kern verwenden, können Sie während der Entwicklung die Zertifikatsüberprüfung mithilfe von Compiler-Anweisungen umgehen. Auf diese Weise wird das Zertifikat nur für die Freigabe und nicht für das Debuggen validiert:

#if (DEBUG)
        client.ClientCredentials.ServiceCertificate.SslCertificateAuthentication =
                new X509ServiceCertificateAuthentication()
                {
                    CertificateValidationMode = X509CertificateValidationMode.None,
                    RevocationMode = System.Security.Cryptography.X509Certificates.X509RevocationMode.NoCheck
                };   #endif

Fügen Sie dies Ihrem Client-Code hinzu:

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