Die Anforderung wurde abgebrochen: Es konnte kein sicherer SSL / TLS-Kanal erstellt werden

WebRequestAufgrund dieser Fehlermeldung können wir keine Verbindung zu einem HTTPS-Server herstellen :

The request was aborted: Could not create SSL/TLS secure channel.

Wir wissen, dass der Server kein gültiges HTTPS-Zertifikat mit dem verwendeten Pfad hat. Um dieses Problem zu umgehen, verwenden wir den folgenden Code, den wir einem anderen StackOverflow-Beitrag entnommen haben:

private void Somewhere() {
    ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(AlwaysGoodCertificate);
}

private static bool AlwaysGoodCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors) {
   return true;
}

Das Problem ist, dass der Server das Zertifikat niemals validiert und mit dem oben genannten Fehler ausfällt. Hat jemand eine Idee, was ich tun soll?

Ich sollte erwähnen, dass ein Kollege und ich vor einigen Wochen Tests durchgeführt haben und es mit etwas ähnlichem wie dem, was ich oben geschrieben habe, gut funktioniert hat. Der einzige "große Unterschied", den wir festgestellt haben, ist, dass ich Windows 7 verwende und er Windows XP verwendet. Ändert das etwas?

Ich habe endlich die Antwort gefunden (ich habe meine Quelle nicht notiert, aber sie stammt von einer Suche);

Während der Code unter Windows XP funktioniert, müssen Sie dies unter Windows 7 am Anfang hinzufügen:

// using System.Net;
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
// Use SecurityProtocolType.Ssl3 if needed for compatibility reasons

Und jetzt funktioniert es perfekt.

NACHTRAG

Wie von Robin French erwähnt; Wenn dieses Problem bei der Konfiguration von PayPal auftritt, beachten Sie bitte, dass SSL3 ab dem 3. Dezember 2018 nicht mehr unterstützt wird. Sie müssen TLS verwenden. Hier ist die Paypal-Seite darüber.

Die Lösung hierfür in .NET 4.5 ist

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Wenn Sie nicht über .NET 4.5 verfügen, verwenden Sie

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

Stellen Sie sicher, dass die ServicePointManager-Einstellungen vorgenommen wurden, bevor die HttpWebRequest erstellt wird. Andernfalls funktioniert sie nicht.

Werke:

        ServicePointManager.Expect100Continue = true;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
               | SecurityProtocolType.Tls11
               | SecurityProtocolType.Tls12
               | SecurityProtocolType.Ssl3;

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

Schlägt fehl:

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

        ServicePointManager.Expect100Continue = true;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
               | SecurityProtocolType.Tls11
               | SecurityProtocolType.Tls12
               | SecurityProtocolType.Ssl3;

Das Problem besteht darin, dass der aspNet-Benutzer keinen Zugriff auf das Zertifikat hat. Sie müssen den Zugriff über die Datei winhttpcertcfg.exe gewähren

Ein Beispiel für die Einrichtung finden Sie unter: http://support.microsoft.com/kb/901183

Unter Schritt 2 finden Sie weitere Informationen

BEARBEITEN: In neueren Versionen von IIS ist diese Funktion in das Zertifikatmanager-Tool integriert. Sie können darauf zugreifen, indem Sie mit der rechten Maustaste auf das Zertifikat klicken und die Option zum Verwalten privater Schlüssel verwenden. Weitere Details finden Sie hier: /server/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791#132791

Der Fehler ist generisch und es gibt viele Gründe, warum die SSL / TLS-Aushandlung fehlschlagen kann. Am häufigsten ist ein ungültiges oder abgelaufenes Serverzertifikat, und Sie haben sich darum gekümmert, indem Sie Ihren eigenen Hook für die Validierung von Serverzertifikaten bereitgestellt haben. Dies ist jedoch nicht unbedingt der einzige Grund. Der Server erfordert möglicherweise eine gegenseitige Authentifizierung. Er kann mit einer Reihe von Chiffren konfiguriert sein, die von Ihrem Client nicht unterstützt werden. Die Zeitverschiebung ist möglicherweise zu groß, als dass der Handshake erfolgreich sein könnte, und viele weitere Gründe.

Die beste Lösung ist die Verwendung des SChannel-Toolsets zur Fehlerbehebung. SChannel ist der SSPI-Anbieter, der für SSL und TLS verantwortlich ist, und Ihr Client wird ihn für den Handshake verwenden. Schauen Sie sich die TLS / SSL-Tools und -Einstellungen an .

Siehe auch Aktivieren der Schannel-Ereignisprotokollierung .

Ich hatte dieses Problem beim Versuch, https://ct.mob0.com/Styles/Fun.png zu erreichen. Dies ist ein Bild, das von CloudFlare auf seinem CDN verteilt wird und verrückte Dinge wie SPDY und seltsame Weiterleitungs-SSL-Zertifikate unterstützt.

Anstatt Ssl3 wie in Simons Antwort anzugeben, konnte ich es beheben, indem ich wie folgt zu Tls12 ging:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png");

Nach vielen langen Stunden mit demselben Problem stellte ich fest, dass das ASP.NET-Konto, unter dem der Clientdienst ausgeführt wurde, keinen Zugriff auf das Zertifikat hatte. Ich habe das Problem behoben, indem ich in den IIS-Anwendungspool gegangen bin, unter dem die Webanwendung ausgeführt wird, in die erweiterten Einstellungen gegangen bin und die Identität des LocalSystemKontos von geändert habe NetworkService.

Eine bessere Lösung besteht darin, das Zertifikat mit dem Standardkonto zum Laufen zu NetworkServicebringen. Dies funktioniert jedoch für schnelle Funktionstests.

Der Ansatz mit Einstellung

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Scheint in Ordnung zu sein, da Tls1.2 die neueste Version des sicheren Protokolls ist. Aber ich habe mich entschlossen, genauer hinzuschauen und zu antworten, ob wir es wirklich fest codieren müssen.

Technische Daten: Windows Server 2012R2 x64.

Aus dem Internet wird mitgeteilt, dass .NetFramework 4.6+ standardmäßig Tls1.2 verwenden muss. Aber als ich mein Projekt auf 4.6 aktualisiert habe, ist nichts passiert. Ich habe einige Informationen gefunden, die besagen, dass ich einige Änderungen manuell vornehmen muss, um Tls1.2 standardmäßig zu aktivieren

https://support.microsoft.com/en-in/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi

Das vorgeschlagene Windows-Update funktioniert jedoch nicht für die R2-Version

Aber was mir geholfen hat, ist das Hinzufügen von 2 Werten zur Registrierung. Sie können das nächste PS-Skript verwenden, damit diese automatisch hinzugefügt werden

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

Das ist genau das, wonach ich gesucht habe. Aber ich kann immer noch nicht auf die Frage antworten, warum NetFramework 4.6+ dies nicht einstellt ... Protokollwert automatisch?

Etwas, das die ursprüngliche Antwort nicht hatte. Ich habe etwas mehr Code hinzugefügt, um es kugelsicher zu machen.

ServicePointManager.Expect100Continue = true;
        ServicePointManager.DefaultConnectionLimit = 9999;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;

Eine andere Möglichkeit ist der unsachgemäße Import von Zertifikaten auf der Box. Stellen Sie sicher, dass das Kontrollkästchen eingekreist aktiviert ist. Anfangs habe ich es nicht getan, daher lief der Code entweder ab oder es wurde dieselbe Ausnahme ausgelöst, da der private Schlüssel nicht gefunden werden konnte.

Die Ausnahme "Die Anforderung wurde abgebrochen: SSL / TLS-sicherer Kanal konnte nicht erstellt werden" kann auftreten, wenn der Server eine nicht autorisierte HTTP 401- Antwort auf die HTTP-Anforderung zurückgibt.

Sie können feststellen, ob dies geschieht, indem Sie die System.Net-Protokollierung auf Trace-Ebene für Ihre Clientanwendung aktivieren, wie in dieser Antwort beschrieben .

Sobald diese Protokollierungskonfiguration vorhanden ist, führen Sie die Anwendung aus und reproduzieren Sie den Fehler. Suchen Sie dann in der Protokollierungsausgabe nach einer Zeile wie der folgenden:

System.Net Information: 0 : [9840] Connection#62912200 - Received status line: Version=1.1, StatusCode=401, StatusDescription=Unauthorized.

In meiner Situation konnte ich kein bestimmtes Cookie setzen, das der Server erwartete, was dazu führte, dass der Server auf die Anfrage mit dem Fehler 401 reagierte, was wiederum zur Ausnahme "SSL / TLS-sicherer Kanal konnte nicht erstellt werden" führte.

Eine weitere mögliche The request was aborted: Could not create SSL/TLS secure channelFehlerursache ist eine Nichtübereinstimmung zwischen den konfigurierten cipher_suites-Werten Ihres Client-PCs und den Werten, die der Server als bereit und in der Lage konfiguriert hat, zu akzeptieren . In diesem Fall sieht der Server, wenn Ihr Client die Liste der cipher_suites-Werte sendet, die er in seiner anfänglichen SSL-Handshake- / Verhandlungsnachricht "Client Hello" akzeptieren kann, dass keiner der angegebenen Werte akzeptabel ist, und gibt möglicherweise eine "Warnung" zurück "Antwort, anstatt mit dem Schritt" Server Hello "des SSL-Handshakes fortzufahren.

Um diese Möglichkeit zu untersuchen, können Sie Microsoft Message Analyzer herunterladen und damit einen Trace für die SSL-Aushandlung ausführen, die auftritt, wenn Sie versuchen, keine HTTPS-Verbindung zum Server herzustellen (in Ihrer C # -App).

Wenn Sie in der Lage sind, eine erfolgreiche HTTPS-Verbindung von einer anderen Umgebung aus herzustellen (z. B. dem von Ihnen erwähnten Windows XP-Computer) oder möglicherweise durch Drücken der HTTPS-URL in einem Nicht-Microsoft-Browser, der die Einstellungen der Cipher Suite des Betriebssystems nicht verwendet, z Führen Sie in dieser Umgebung einen weiteren Message Analyzer-Trace aus, um zu erfassen, was passiert, wenn die SSL-Aushandlung erfolgreich ist.

Hoffentlich sehen Sie einen Unterschied zwischen den beiden Client-Hello-Nachrichten, mit denen Sie genau bestimmen können, was mit der fehlgeschlagenen SSL-Aushandlung zu einem Fehlschlag führt. Dann sollten Sie in der Lage sein, Konfigurationsänderungen an Windows vorzunehmen, die den Erfolg ermöglichen. IISCrypto ist hierfür ein großartiges Tool (auch für Client-PCs, trotz des Namens "IIS").

Die folgenden zwei Windows-Registrierungsschlüssel regeln die cipher_suites-Werte, die Ihr PC verwendet:

• HKLM \ SOFTWARE \ Policies \ Microsoft \ Cryptography \ Configuration \ SSL \ 00010002
• HKLM \ SYSTEM \ CurrentControlSet \ Control \ Cryptography \ Configuration \ Local \ SSL \ 00010002

Hier finden Sie eine vollständige Beschreibung, wie ich eine Instanz dieser Art von Could not create SSL/TLS secure channelProblem untersucht und gelöst habe : http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in-windows.html

Die Wurzel dieser Ausnahme in meinem Fall war, dass irgendwann im Code Folgendes aufgerufen wurde:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Das ist wirklich schlimm. Es weist .NET nicht nur an, ein unsicheres Protokoll zu verwenden, sondern wirkt sich auch auf jede neue WebClient- (und ähnliche) Anforderung aus, die anschließend in Ihrer Appdomain gestellt wird. (Beachten Sie, dass eingehende Webanforderungen in Ihrer ASP.NET-App nicht betroffen sind, neue WebClient-Anforderungen, z. B. um mit einem externen Webdienst zu kommunizieren, jedoch nicht betroffen sind.)

In meinem Fall wurde es nicht wirklich benötigt, sodass ich die Anweisung einfach löschen konnte und alle anderen Webanfragen wieder einwandfrei funktionierten. Aufgrund meiner Lektüre an anderer Stelle habe ich einige Dinge gelernt:

• Dies ist eine globale Einstellung in Ihrer Appdomain. Wenn Sie gleichzeitig aktiv sind, können Sie sie nicht zuverlässig auf einen Wert festlegen, Ihre Aktion ausführen und sie dann zurücksetzen. Eine andere Aktion kann während dieses kleinen Fensters stattfinden und beeinflusst werden.
• Die richtige Einstellung ist, die Standardeinstellung beizubehalten. Auf diese Weise kann .NET im Laufe der Zeit weiterhin den sichersten Standardwert verwenden und Sie aktualisieren Frameworks. Das Einstellen auf TLS12 (das zum Zeitpunkt des Schreibens am sichersten ist) funktioniert jetzt, kann jedoch in 5 Jahren zu mysteriösen Problemen führen.
• Wenn Sie wirklich einen Wert festlegen müssen, sollten Sie dies in einer separaten speziellen Anwendung oder Appdomain tun und einen Weg finden, zwischen ihm und Ihrem Hauptpool zu sprechen. Da es sich um einen einzelnen globalen Wert handelt, führt der Versuch, ihn in einem ausgelasteten App-Pool zu verwalten, nur zu Problemen. Diese Antwort: https://stackoverflow.com/a/26754917/7656 bietet eine mögliche Lösung über einen benutzerdefinierten Proxy. (Hinweis Ich habe es nicht persönlich implementiert.)

Ich hatte dieses Problem, weil meine web.config hatte:

<httpRuntime targetFramework="4.5.2" />

und nicht:

<httpRuntime targetFramework="4.6.1" />

Wie Sie sehen, gibt es viele Gründe, warum dies passieren könnte. Ich dachte, ich würde die Ursache hinzufügen, auf die ich gestoßen bin ...

Wenn Sie den Wert WebRequest.Timeoutauf setzen 0, ist dies die Ausnahme, die ausgelöst wird. Unten ist der Code, den ich hatte ... (Außer anstelle eines fest codierten Codes 0für den Timeout-Wert hatte ich einen Parameter, der versehentlich auf gesetzt wurde 0).

WebRequest webRequest = WebRequest.Create(@"https://myservice/path");
webRequest.ContentType = "text/html";
webRequest.Method = "POST";
string body = "...";
byte[] bytes = Encoding.ASCII.GetBytes(body);
webRequest.ContentLength = bytes.Length;
var os = webRequest.GetRequestStream();
os.Write(bytes, 0, bytes.Length);
os.Close();
webRequest.Timeout = 0; //setting the timeout to 0 causes the request to fail
WebResponse webResponse = webRequest.GetResponse(); //Exception thrown here ...

Die am besten gewählte Antwort wird wahrscheinlich für die meisten Menschen ausreichen. Unter bestimmten Umständen kann jedoch auch nach dem Erzwingen von TLS 1.2 weiterhin der Fehler "SSL / TLS-sicherer Kanal konnte nicht erstellt werden" angezeigt werden. In diesem Fall können Sie diesen hilfreichen Artikel lesenfür zusätzliche Schritte zur Fehlerbehebung. Zusammenfassend: Unabhängig vom Problem mit der TLS / SSL-Version müssen sich Client und Server auf eine "Cipher Suite" einigen. Während der "Handshake" -Phase der SSL-Verbindung listet der Client seine unterstützten Cipher-Suites auf, damit der Server sie anhand seiner eigenen Liste überprüfen kann. Auf einigen Windows-Computern wurden jedoch möglicherweise bestimmte gängige Cipher-Suites deaktiviert (anscheinend aufgrund gut gemeinter Versuche, die Angriffsfläche zu begrenzen), wodurch die Möglichkeit verringert wurde, dass sich Client und Server auf eine Cipher-Suite einigen. Wenn sie nicht übereinstimmen können, wird in der Ereignisanzeige möglicherweise "Schwerwiegender Warncode 40" und in Ihrem .NET-Programm "Sicherer SSL / TLS-Kanal konnte nicht erstellt werden" angezeigt.

In dem oben genannten Artikel wird erläutert, wie Sie alle potenziell unterstützten Verschlüsselungssuiten eines Computers auflisten und zusätzliche Verschlüsselungssuiten über die Windows-Registrierung aktivieren. Besuchen Sie diese Diagnoseseite in MSIE, um zu überprüfen, welche Cipher Suites auf dem Client aktiviert sind . (Die Verwendung der System.Net-Ablaufverfolgung kann zu endgültigeren Ergebnissen führen.) Um zu überprüfen, welche Cipher Suites vom Server unterstützt werden, versuchen Sie dieses Online-Tool (vorausgesetzt, der Server ist über das Internet zugänglich). Es versteht sich von selbst, dass Registrierungsänderungen mit Vorsicht vorgenommen werden müssen , insbesondere wenn es um Netzwerke geht. (Handelt es sich bei Ihrem Computer um eine remote gehostete VM? Wenn Sie das Netzwerk unterbrechen würden, wäre die VM überhaupt verfügbar?)

Im Fall meines Unternehmens haben wir mehrere zusätzliche "ECDHE_ECDSA" -Suiten über die Registrierungsbearbeitung aktiviert, um ein sofortiges Problem zu beheben und zukünftige Probleme zu vermeiden. Wenn Sie die Registrierung jedoch nicht bearbeiten können (oder wollen), fallen Ihnen zahlreiche (nicht unbedingt hübsche) Problemumgehungen ein. Beispiel: Ihr .NET-Programm könnte seinen SSL-Verkehr an ein separates Python-Programm delegieren (was möglicherweise selbst funktioniert, aus demselben Grund, aus dem Chrome-Anforderungen möglicherweise erfolgreich sind, wenn MSIE-Anforderungen auf einem betroffenen Computer fehlschlagen).

Eine der Hauptursachen für dieses Problem ist die aktive .NET Framework-Version. Die Laufzeitversion von .NET Framework beeinflusst, welche Sicherheitsprotokolle standardmäßig aktiviert sind.

Es scheint keine maßgebliche Dokumentation darüber zu geben, wie es in verschiedenen Versionen speziell funktioniert, aber es scheint, dass die Standardeinstellungen mehr oder weniger wie folgt festgelegt werden:

• .NET Framework 4.5 und früher - SSL 3.0, TLS 1.0
• .NET Framework 4.6.x - TLS 1.0, 1.1, 1.2, 1.3
• .NET Framework 4.7+ - Systemstandards

(Bei älteren Versionen kann Ihr Kilometerstand je nach den auf dem System installierten .NET-Laufzeiten etwas variieren. Beispielsweise kann es vorkommen, dass Sie ein sehr altes Framework verwenden und TLS 1.0 nicht unterstützt wird oder 4.6 verwendet. x und TLS 1.3 werden nicht unterstützt)

In der Microsoft-Dokumentation wird dringend empfohlen, 4.7+ und die Systemstandards zu verwenden:

Wir empfehlen Ihnen:

• Zielen Sie auf .NET Framework 4.7 oder neuere Versionen Ihrer Apps ab. Zielen Sie auf .NET Framework 4.7.1 oder neuere Versionen Ihrer WCF-Apps ab.
• Geben Sie nicht die TLS-Version an. Konfigurieren Sie Ihren Code so, dass das Betriebssystem über die TLS-Version entscheidet.
• Führen Sie eine gründliche Codeprüfung durch, um sicherzustellen, dass Sie keine TLS- oder SSL-Version angeben.

Überprüfen Sie für ASP.NET-Sites die .NET Framework-Version in Ihrem <httpRuntime>Element, da dies bestimmt, welche Laufzeit von Ihrer Site tatsächlich verwendet wird:

<httpRuntime targetFramework="4.5" />

Besser:

<httpRuntime targetFramework="4.7" />

Dieser arbeitet für mich im MVC-Webclient

    public string DownloadSite(string RefinedLink)
    {
        try
        {
            Uri address = new Uri(RefinedLink);

            ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
            ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

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

            using (WebClient webClient = new WebClient())
            {
                var stream = webClient.OpenRead(address);
                using (StreamReader sr = new StreamReader(stream))
                {
                    var page = sr.ReadToEnd();

                    return page;
                }
            }

        }
        catch (Exception e)
        {
            log.Error("DownloadSite - error Lin = " + RefinedLink, e);
            return null;
        }
    }

Falls der Client ein Windows-Computer ist, kann ein möglicher Grund darin liegen, dass das vom Dienst geforderte tls- oder ssl-Protokoll nicht aktiviert ist.

Dies kann eingestellt werden in:

Systemsteuerung -> Netzwerk und Internet -> Internetoptionen -> Erweitert

Scrollen Sie mit den Einstellungen nach unten zu "Sicherheit" und wählen Sie zwischen

• Verwenden Sie SSL 2.0
• Verwenden Sie SSL 3.0
• Verwenden Sie TLS 1.0
• Verwenden Sie TLS 1.1
• Verwenden Sie TLS 1.2

In meinem Fall hatte das Dienstkonto, auf dem die Anwendung ausgeführt wurde, keine Berechtigung zum Zugriff auf den privaten Schlüssel. Nachdem ich diese Erlaubnis gegeben hatte, verschwand der Fehler

1. mmc
2. Zertifikate
3. Erweitern Sie auf persönlich
4. Zertifikat auswählen
5. Rechtsklick
6. Alle Aufgaben
7. Private Schlüssel verwalten
8. Hinzufügen

Wenn Sie Ihren Code in Visual Studio ausführen, versuchen Sie, Visual Studio als Administrator auszuführen. Das Problem wurde für mich behoben.

Ich habe den ganzen Tag mit diesem Problem zu kämpfen.

Als ich mit .NET 4.5 ein neues Projekt erstellt habe, habe ich es endlich zum Laufen gebracht.

Aber wenn ich auf 4.0 heruntergestuft habe, habe ich wieder das gleiche Problem und es war für dieses Projekt irreversibel (selbst wenn ich versucht habe, erneut auf 4.5 zu aktualisieren).

Seltsamerweise keine andere Fehlermeldung als "Die Anforderung wurde abgebrochen: SSL / TLS-sicherer Kanal konnte nicht erstellt werden." kam für diesen Fehler

System.Net.WebException: Die Anforderung wurde abgebrochen: Es konnte kein sicherer SSL / TLS-Kanal erstellt werden.

In unserem Fall haben wir einen Softwareanbieter verwendet, sodass wir keinen Zugriff hatten, um den .NET-Code zu ändern. Anscheinend wird .NET 4 TLS v 1.2 nur verwenden, wenn eine Änderung vorliegt.

Das Update für uns war das Hinzufügen des SchUseStrongCrypto-Schlüssels zur Registrierung. Sie können den folgenden Code mit der Erweiterung .reg in eine Textdatei kopieren / einfügen und ausführen. Es diente als unser "Patch" für das Problem.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

Versuche dies:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Dies wurde für mich behoben. Fügen Sie den Berechtigungen den Netzwerkdienst hinzu. Klicken Sie mit der rechten Maustaste auf das Zertifikat> Alle Aufgaben> Private Schlüssel verwalten ...> Hinzufügen ...> "Netzwerkdienst" hinzufügen.

Das Problem für mich war, dass ich versucht habe, IIS als Webdienst bereitzustellen. Ich habe das Zertifikat auf dem Server installiert, aber der Benutzer, der IIS ausführt, hatte nicht die richtigen Berechtigungen für das Zertifikat.

Wie kann ASP.NET Zugriff auf einen privaten Schlüssel in einem Zertifikat im Zertifikatspeicher erhalten?

Ich hatte das gleiche Problem und fand, dass diese Antwort für mich richtig funktionierte. Der Schlüssel ist 3072. Dieser Link enthält die Details zum Fix '3072'.

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

XmlReader r = XmlReader.Create(url);
SyndicationFeed albums = SyndicationFeed.Load(r);

In meinem Fall erforderten zwei Feeds den Fix:

https://www.fbi.gov/feeds/fbi-in-the-news/atom.xml
https://www.wired.com/feed/category/gear/latest/rss

Diese Frage kann viele Antworten haben, da es sich um eine allgemeine Fehlermeldung handelt. Dieses Problem ist auf einigen unserer Server aufgetreten, nicht jedoch auf unseren Entwicklungsmaschinen. Nachdem wir den größten Teil unserer Haare herausgezogen hatten, stellten wir fest, dass es sich um einen Microsoft-Fehler handelte.

https://support.microsoft.com/en-us/help/4458166/applications-that-rely-on-tls-1-2-strong-encryption-experience-connect

Im Wesentlichen geht MS davon aus, dass Sie eine schwächere Verschlüsselung wünschen, das Betriebssystem ist jedoch so gepatcht, dass nur TLS 1.2 zulässig ist. Daher erhalten Sie die gefürchtete Meldung "Die Anforderung wurde abgebrochen: Sicherer SSL / TLS-Kanal konnte nicht erstellt werden."

Es gibt drei Korrekturen.

1) Patchen Sie das Betriebssystem mit dem richtigen Update: http://www.catalog.update.microsoft.com/Search.aspx?q=kb4458166

2) Fügen Sie Ihrer Datei app.config / web.config eine Einstellung hinzu.

3) Fügen Sie eine Registrierungseinstellung hinzu, die bereits in einer anderen Antwort erwähnt wurde.

All dies wird in dem von mir veröffentlichten Knowledge Base-Artikel erwähnt.

Eine andere Möglichkeit besteht darin, dass der ausgeführte Code nicht die erforderlichen Prämissen aufweist.

In meinem Fall wurde dieser Fehler angezeigt, wenn ich den Visual Studio-Debugger zum Testen eines Aufrufs eines Webdienstes verwendete. Visual Studio wurde nicht als Administrator ausgeführt, was diese Ausnahme verursachte.

Dies geschah für mich nur an einer Stelle, und es stellte sich heraus, dass nur die RC4-Verschlüsselung verfügbar war. In einem früheren Versuch, den Server zu härten, hatte ich die RC4-Verschlüsselung deaktiviert. Nachdem ich dies wieder aktiviert hatte, wurde das Problem behoben.