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

429

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?

Simon Dugré
quelle
3
Überprüfen Sie dies auch stackoverflow.com/questions/1600743/…
Oskar Kjellin
51
Es ist 2018 und diese Frage wurde 308.056 Mal angesehen, aber es gibt immer noch keine richtige Lösung dafür !! Ich bekomme dieses Problem zufällig und keine der hier oder in anderen Threads erwähnten Korrekturen hat mein Problem gelöst.
Nigel Fds
3
@NigelFds Der Fehler The request was aborted: Could not create SSL/TLS secure channelist sehr allgemein. Grundsätzlich heißt es: "Die Initialisierung der SSL / TLS / HTTPS-Verbindung ist aus einem von vielen möglichen Gründen fehlgeschlagen." Wenn Sie es also regelmäßig in einer bestimmten Situation erhalten, ist es am besten, eine bestimmte Frage zu stellen, die bestimmte Details zu dieser Situation enthält. Weitere Informationen finden Sie in der Ereignisanzeige. Und / oder aktivieren Sie ein clientseitiges .NET-Debugging, um weitere Details zu erhalten (ist das Serverzertifikat nicht vertrauenswürdig? Gibt es eine Nichtübereinstimmung der Verschlüsselung? Nicht übereinstimmende SSL / TLS-Protokollversionen usw.).
MarnixKlooster ReinstateMonica
4
@MarnixKlooster Ich habe das alles bereits überprüft. Es kann kein Problem mit dem Zertifikat sein, als ob ich es erneut versuche, es funktioniert. Und ich bezweifle, dass ich diese Frage auf SO stellen kann, ohne dass jemand kommt und sie als Duplikat oder so markiert.
Nigel Fds
1
Ich kämpfe dieses Problem vielleicht zum 4. Mal. Die gleiche Codebasis, die ich verwende, funktioniert gut in der Produktion und auch in der Entwicklungsumgebung einiger meiner Entwicklerkollegen. Beim letzten Mal wurde ich angewiesen, einen Registrierungswert Computer \ HKEY_LOCAL_MACHINE \ SOFTWARE \ WOW6432Node \ Microsoft \ .NETFramework \ v4.7.02046 \ SchUseStrongCrypto [DWORD] = 1 hinzuzufügen. Und es funktionierte eine Weile. Ich habe eine Zeit lang angefangen, in einem anderen Projekt zu arbeiten, und jetzt bin ich wieder bei diesem Projekt und die Anfrage schlägt erneut fehl, selbst mit diesem Registrierungsschlüssel-Fix. Sehr nervig.
Miguel

Antworten:

595

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.

Simon Dugré
quelle
5
Wenn ich zu SecurityProtocolType.Tls12 gehe, wurde dieses Problem für mich behoben. Siehe meine Antwort unten.
Bryan Legend
24
SSLv3 ist 18 Jahre alt und jetzt anfällig für die POODLE ausnutzen - wie @LoneCoder empfiehlt SecurityProtocolType.Tls12 die geeigneten Ersatz für SecurityProtocolType.Ssl3 ist
Gary
4
SecurityProtocolType.Tls könnte tatsächlich eine bessere Alternative sein, bis ein Exploit dafür gefunden wird (nicht alle Sites unterstützen Tls12 zum Zeitpunkt des Schreibens)
Gary
3
PayPal hat ein Datum vom 30. Juni 2017 festgelegt, um SSL3 zu deaktivieren und TLS1.2 zu implementieren. Es wird bereits in ihrer Sandbox-Umgebung angewendet. Paypal-knowledge.com/infocenter/…
Robin French
11
Sehen Sie das auch. Sie müssen es nicht ausschließlich auf einen einzelnen Typ festlegen, sondern können es auch einfach anhängen. System.Net.ServicePointManager.SecurityProtocol |= System.Net.SecurityProtocolType.Tls12;
Nae
153

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;
Andrej Z.
quelle
10
Vielen Dank! Ich muss .net 4.0 verwenden und wusste nicht, wie ich das lösen soll. Das scheint hier zu funktionieren. :)
Fabiano
Funktioniert nicht unter Windows Server 2008R2 (und möglicherweise auch 2012)
Misam
@ Billpg, lesen Sie dies für eine genauere Antwort
Vikrant
Für VB-Typen (da diese Antwort in Google angezeigt wird) lautet der entsprechende CodeServicePointManager.SecurityProtocol = DirectCast(3072, SecurityProtocolType)
ConfusionTowers
@Andrej Z arbeitet an .net Framework 4. Danke.
Az Fav
107

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;
hogarth45
quelle
4
Was ist der Unterschied zwischen Works und Fails, die Sie oben erwähnt haben?
Chandy Kunhu
5
Genial. Meine Anfrage funktionierte erst nach dem zweiten Versuch, was keinen Sinn machte und dann sah ich Ihren Beitrag, verschob das Sicherheitsprotokoll vor der Anfrage und voilà, behoben. Danke @ hogarth45
Deanwilliammills
2
Genau! Als ich ServicePointManager kurz vor dem Erstellen der Anfrage platzierte, funktionierte es für mich. Danke Mann, Sie haben meinen Tag gerettet.
1
Perfekt ... das ist wunderbar
Maryam Bagheri
1
In unserem Fall ist die Anfrage zum ersten Mal fehlgeschlagen und hat danach funktioniert. Das lag genau an dem in dieser Antwort angegebenen Grund!
Mohammad Dehghan
34

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

Avitus
quelle
Ich habe versucht, winhttpcertcfg.exe auszuführen. Beachten Sie, dass ich unter Windows 7 bin. Kann es etwas ändern?
Simon Dugré
Ich bin nicht sicher, ob es verwandt ist, aber dieser Beitrag brachte mich auf die Idee, VS als Administrator auszuführen, wenn ich diesen Anruf von VS aus tätige, und das hat das Problem für mich behoben.
PFranchise
2
In Windows 7 und höher muss sich das Zertifikat im Speicher für den lokalen Computer und nicht für den aktuellen Benutzer befinden, um "Private Schlüssel verwalten" zu können
Lukos
1
Ja, das war mein Problem. Verwenden Sie mmc.exe, fügen Sie das Zertifikat-Snap-In hinzu (für mich habe ich dann 'lokaler Computer' ausgewählt). Klicken Sie mit der rechten Maustaste auf Zertifikat, alle Aufgaben, verwalten Sie private Schlüssel. Fügen Sie "Jeder" hinzu (für lokale Entwickler ist dies am einfachsten - prod benötigt offensichtlich Ihren expliziten IIS-Website-App-Pool / Benutzer)
Ian Yates
@ Ian Yates, diese Lösung hat nur für mich (y)
funktioniert
31

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 .

Remus Rusanu
quelle
Wo ist der Weg für die Schannel event loggingin Windows - 7-8-10 ?
PreguntonCojoneroCabrón
troubleshoot TLS / SSL programatically in C #?
Kiquenet
27

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");
Bryan Legend
quelle
Danke Lone ... das ist verrückt, wie es je nach Situation viele verschiedene Möglichkeiten von Problemen zu geben scheint ... Und wie ich sehen kann, gibt es keine wirkliche Dokumentation dafür. Nun, danke an jemanden, der möglicherweise das gleiche Problem hat.
Simon Dugré
Das hat bei mir funktioniert. Ich habe den Fehler festgestellt, als ich vom Office-LAN zu meinem Heimnetzwerk gewechselt bin. Gleicher Code, gleicher Laptop!
Amal
Erhalten Sie den Fehler immer (in allen Anfragen) oder manchmal ?
PreguntonCojoneroCabrón
24

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.

Nick Gotch
quelle
3
Diese Antwort sollte mehr Stimmen haben. Nach einer Woche Recherche ist dies die einzige Lösung, die für mich funktioniert hat. Vielen Dank!!
user224567893
Das hat bei mir funktioniert. perfekt danke.
Emy Stats
18

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?

einfach gut
quelle
17

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;
SpoiledTechie.com
quelle
8
Ich würde das hinzugefügte SSL3-Protokoll nicht empfehlen.
Peter de Bruijn
SSL3 hat ein schwerwiegendes Sicherheitsproblem namens "Pudel".
Peter de Bruijn
@PeterdeBruijn Tls and Tls11sind veraltet ?
Kiquenet
1
@ Kiquenet - ja. Ab Juni 2018 erlaubt die PCI (Payment Card Industries) keine Protokolle unter TLS1.2. (Dies war ursprünglich für 06/2017 geplant, wurde aber um ein Jahr verschoben)
GlennG
Es gibt fünf Protokolle in der SSL / TLS-Familie: SSL v2, SSL v3, TLS v1.0, TLS v1.1 und TLS v1.2 : github.com/ssllabs/research/wiki/… SSL v2 unsecure, SSL v3 is insecure when used with HTTP (the POODLE attack), TLS v1.0, TLS v1.1 obsoletes Nur gültige Option ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12?
Kiquenet
14

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.

Dialog zum Importieren von Zertifikaten

Sherlock
quelle
Ein Client musste das Zertifikat immer wieder neu installieren, um ein Client-Programm verwenden zu können. Immer wieder müssten sie das Zertifikat neu installieren, bevor sie das Programm verwenden können. Ich hoffe, diese Antwort behebt dieses Problem.
Pangamma
11

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.

Jon Schneider
quelle
1
Mein Task - Scheduler jeden Tag (Wochenende) ausführen. Ich bekomme den gleichen Fehler, aber manchmal ( 2 errors in 2 months). Wenn ich den Fehler erhalte, versuche ich es später einige Minuten erneut manuell und alles ist in Ordnung.
Kiquenet
10

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

Jon Schneider
quelle
1
In meinem Fall ist diese Antwort hilfreich. Da ich den Verdacht hatte, dass mein Client-PC einige Cipher Suites verpasst hat, habe ich eine Verknüpfung verwendet und dieses Windows Update direkt installiert, um mein Glück zu versuchen ( support.microsoft.com/en-hk/help/3161639 , muss Windows neu starten), bevor ich das System wirklich starte Message Analyzer-Suche, und es stellte sich heraus, dass ich Glück hatte und mein Problem dadurch gelöst wurde, dass ich mir eine Suche ersparte.
sken130
1
Beachten Sie, dass beim Testen eines HTTPS-Links in Browsern wie Firefox das Windows Update immer noch einen Versuch wert ist, auch wenn Sie eine andere Verschlüsselung als die von einem bestimmten Windows Update bereitgestellten erhalten, da die Installation neuer Chiffren die Verschlüsselungsverhandlung beeinflusst zwischen dem Client-PC und dem Server, wodurch die Hoffnung auf eine Übereinstimmung erhöht wird.
sken130
Auf den Punkt Antwort für mein Problem. Zwei Dinge, die mir geholfen haben, die Änderungen zu finden. 1. Vom Webserver unterstützte Cipher Suites: ssllabs.com/ssltest 2. Von verschiedenen Windows-Versionen unterstützte Cipher Suites: docs.microsoft.com/en-us/windows/win32/secauthn/…
Paul B.
10

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.)
Tyler Forsythe
quelle
2
Entgegen Ihrer allgemeinen Faustregel möchte ich hinzufügen, dass es eine Ausnahme gibt, wenn Sie TLS 1.2 festlegen MÜSSEN, anstatt die Standardeinstellung ausführen zu lassen. Wenn Sie sich in einem älteren Framework als .NET 4.6 befinden und unsichere Protokolle auf Ihrem Server (SSL oder TLS 1.0 / 1.1) deaktivieren, können Sie keine Anforderungen ausgeben, es sei denn, Sie erzwingen das Programm in TLS 1.2.
Paul
10

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

<httpRuntime targetFramework="4.5.2" />

und nicht:

<httpRuntime targetFramework="4.6.1" />
Terje Solem
quelle
Ich hatte das gleiche Problem und habe unten eine detailliertere Antwort hinzugefügt , die mehr auf die Vor- und Nachteile dieses Problems eingeht.
JLRishe
9

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 ...
TCC
quelle
2
Beeindruckend! Vielen Dank, dass Sie dies erwähnt haben. Konnte das überhaupt nicht glauben und probierte zuerst Tonnen verschiedener Dinge aus. Stellen Sie dann endlich das Timeout auf 10 Sekunden ein und die Ausnahme ist verschwunden! Das ist die Lösung für mich. (y)
derFunk
9

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).

APW
quelle
9

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" />
JLRishe
quelle
8

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;
        }
    }
Arun Prasad ES
quelle
2
Würde das Überschreiben von ServerCertificateValidationCallback eine neue Sicherheitslücke einführen?
7

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

Geben Sie hier die Bildbeschreibung ein

cnom
quelle
Gibt es ein Problem beim Ankreuzen aller?
Nigel Fds
Keine Probleme, soweit ich weiß ... außer dass SSL nicht mehr empfohlen werden ... sie werden nicht als sicher genug angesehen.
cnom
Wie geht das programmgesteuert in Powershell?
Kiquenet
Dies wirkt sich auf ältere Windows-Versionen aus. Führen Sie Nachforschungen durch und finden Sie heraus, welche Sicherheitsoptionen derzeit verwendet werden. Ab heute siehe diesen Link: tecadmin.net/enable-tls-on-windows-server-and-iis
Tod
7

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
Dinesh Rajan
quelle
7

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

bplus
quelle
Leider nicht für mich!
benedict_w
Dies ist der einzige, der in meinem Fall geholfen hat! Vielen Dank!!!
Alexander Ostrikov
6

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

ein Geist
quelle
5
Der Grund dafür war möglicherweise, dass verschiedene .NET-Versionen unterschiedliche SSL / TLS-Protokollversionen unterstützen. Weitere Informationen: blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support
Jon Schneider
4

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
Capdragon
quelle
3
Hier PS für die schnelle Bearbeitung: New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value "1" -Type DWord
Tilo
2
Hier PS für die schnelle Bearbeitung2:New-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value "1" -Type DWord
Tilo
4

Versuche dies:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
Muhammad Awais
quelle
Ich habe diese Zeile hinzugefügt. Manchmal schlägt es fehl und ich bekomme den gleichen FehlerSystem.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
Joseph Katzman
4

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.

jayasurya_j
quelle
3

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?

Danny Cullen
quelle
Ja, ebenso. Um das Problem zu beheben, habe ich die Antwort von Nick Gotch ausgeführt: Die Identität des App-Pools wurde in LocalSystem geändert. Das hat es für mich gelöst.
Judah Gabriel Himango
1
Danke dafür
Denis Pitcher
3

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
Joeydood
quelle
3

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.

Michael Silver
quelle
Stellen Sie außerdem sicher, dass Sie ServicePointManager.SecurityProtocol nur einmal in Ihrer App festlegen. Wir haben in unserer App einen zweiten Aufruf entdeckt (der ziemlich komplex ist, da optionale Assemblys zur Laufzeit geladen werden), der ihn auf SSL3 gesetzt hat und dann dieselbe Fehlermeldung ausgegeben hat.
Michael Silver
3

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.

HeyJude
quelle
2

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.

Mark Reid
quelle
1
Verwenden Sie keine Links für Antworten, da diese in Zukunft möglicherweise nicht funktionieren.
Rodrigo López,