it-swarm.com.de

Die Anforderung wurde abgebrochen: Der sichere SSL / TLS-Kanal konnte nicht erstellt werden

Wir können mit WebRequest keine Verbindung zu einem HTTPS-Server herstellen, da folgende Fehlermeldung angezeigt wird:

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

Wir wissen, dass der Server über kein gültiges HTTPS-Zertifikat mit dem verwendeten Pfad verfügt. Um dieses Problem zu umgehen, verwenden wir den folgenden Code, den wir aus 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 nie überprüft und mit dem oben genannten Fehler fehlschlägt. Hat jemand eine Idee, was ich tun soll?


Ich sollte erwähnen, dass ein Kollege und ich vor ein paar 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?

317
Simon Dugré

Ich fand schließlich die Antwort (ich habe meine Quelle nicht notiert, aber sie stammte von einer Suche);

Während der Code unter Windows XP und Windows 7 funktioniert, müssen Sie dies 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, wird SSL3 ab dem 3. Dezember 2018 nicht mehr unterstützt. Sie müssen TLS verwenden. Hier ist Paypal-Seite darüber.

462
Simon Dugré

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

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Wenn Sie .NET 4.5 nicht haben, verwenden Sie

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
102
Andrej Z

Stellen Sie sicher, dass die ServicePointManager-Einstellungen vorgenommen wurden, bevor die HTTP-Webanforderung 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;
64
hogarth45

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

Ein Beispiel zur Einrichtung finden Sie unter: http://support.Microsoft.com/kb/90118

Unter Schritt 2 erfahren Sie mehr

BEARBEITEN: In neueren Versionen von IIS ist diese Funktion in das Zertifikat-Manager-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 Informationen finden Sie hier: https://serverfault.com/questions/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791#132791

31
Avitus

Der Fehler ist generisch und es gibt viele Gründe, warum die SSL/TLS-Aushandlung fehlschlagen kann. Das häufigste Problem ist ein ungültiges oder abgelaufenes Serverzertifikat. Sie haben dafür einen eigenen Haken zur Überprüfung des Serverzertifikats angegeben, dies ist jedoch nicht unbedingt der einzige Grund. Der Server erfordert möglicherweise eine gegenseitige Authentifizierung, ist möglicherweise mit einer Reihe von Verschlüsselungen konfiguriert, die von Ihrem Client nicht unterstützt werden, weist möglicherweise eine zu große Zeitverschiebung auf, damit der Handshake erfolgreich ist, und viele weitere Gründe.

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

Siehe auch Aktivieren der Schannel-Ereignisprotokollierung .

27
Remus Rusanu

Ich hatte dieses Problem beim Versuch, https://ct.mob0.com/Styles/Fun.png zu treffen, ein von CloudFlare auf dem CDN verteiltes Bild, das verrückte Dinge wie SPDY und seltsames Redirect-SSL unterstützt Zertifikate.

Anstatt Ssl3 wie in Simons answer anzugeben, konnte ich das Problem beheben, indem ich folgendermaßen zu Tls12 ging:

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

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 von LocalSystem in NetworkService geändert habe.

Eine bessere Lösung besteht darin, das Zertifikat mit dem Standardkonto NetworkService arbeiten zu lassen, dies funktioniert jedoch für schnelle Funktionstests.

19
Nick Gotch

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;
14

Eine andere Möglichkeit ist ein fehlerhafter Zertifikatimport auf der Box. Stellen Sie sicher, dass das Kontrollkästchen "Eingekreist" aktiviert ist. Anfänglich habe ich es nicht getan, daher lief der Code ab oder es wurde die gleiche Ausnahme ausgelöst, da der private Schlüssel nicht gefunden werden konnte.

certificate importation dialog

13
Sherlock

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

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

Sobald diese Protokollierungskonfiguration eingerichtet 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 ein bestimmtes Cookie, das der Server erwartet hatte, nicht setzen. Dies führte dazu, dass der Server auf die Anforderung mit dem Fehler 401 antwortete, der wiederum zur Ausnahme "SSL/TLS Secure Channel konnte nicht erstellt werden" führte.

10
Jon Schneider

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

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Das ist wirklich schlimm. .NET wird nicht nur angewiesen, ein unsicheres Protokoll zu verwenden, sondern es wirkt sich auch auf alle neuen WebClient-Anforderungen (und ähnliche Anforderungen) aus, die anschließend in Ihrer Appdomäne gestellt werden. (Beachten Sie, dass eingehende Webanforderungen in Ihrer ASP.NET-App nicht betroffen sind, neue WebClient-Anforderungen, z. B. für die Kommunikation mit einem externen Webdienst, jedoch).

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

  • Dies ist eine globale Einstellung in Ihrer App-Domäne. Wenn Sie gleichzeitig Aktivitäten ausführen, können Sie sie nicht zuverlässig auf einen Wert setzen, 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 können Frameworks aktualisieren. Die Einstellung auf TLS12 (die zum Zeitpunkt des Schreibens am sichersten ist) funktioniert jetzt , kann jedoch in 5 Jahren zu mysteriösen Problemen führen.
  • Wenn Sie einen Wert wirklich festlegen müssen, sollten Sie ihn in einer separaten speziellen Anwendung oder Appdomain ausführen und eine Möglichkeit finden, zwischen ihm und Ihrem Hauptpool zu kommunizieren. Da es sich um einen einzigen globalen Wert handelt, führt der Versuch, ihn in einem ausgelasteten App-Pool zu verwalten, nur zu Problemen. Diese Antwort lautet: https://stackoverflow.com/a/26754917/7656 bietet eine mögliche Lösung über einen benutzerdefinierten Proxy. (Beachten Sie, dass ich es nicht persönlich implementiert habe.)
9
Tyler Forsythe

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;
        }
    }
9
Arun Prasad E S

Wie Sie sehen, kann dies viele Gründe haben. Dachte, ich würde die Ursache hinzufügen, auf die ich gestoßen bin ...

Wenn Sie den Wert von WebRequest.Timeout auf 0 setzen, ist dies die Ausnahme, die ausgelöst wird. Unten ist der Code, den ich hatte ... (Mit Ausnahme eines hartcodierten 0 für den Timeout-Wert hatte ich einen Parameter, der versehentlich auf 0 gesetzt wurde).

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 ...
8
TCC

Eine weitere mögliche Ursache für den Fehler The request was aborted: Could not create SSL/TLS secure channel 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 erkennt der Server, wenn Ihr Client die Liste der cipher_suites-Werte sendet, die er in seiner anfänglichen SSL-Handshake-/Aushandlungsnachricht "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 eine Ablaufverfolgung für die SSL-Aushandlung ausführen, die auftritt, wenn Sie versuchen, keine HTTPS-Verbindung zum Server herzustellen (in Ihrer C # -Anwendung) ).

Wenn Sie in der Lage sind, eine erfolgreiche HTTPS-Verbindung von einer anderen Umgebung (z. B. dem von Ihnen erwähnten Windows XP - Computer aus herzustellen, oder wenn Sie die HTTPS-URL in einem Browser eines anderen Herstellers als Microsoft eingeben, der die Betriebssysteme nicht verwendet Cipher Suite-Einstellungen wie Chrome oder Firefox) führen einen weiteren Message Analyzer-Trace in dieser Umgebung aus, um zu erfassen, was passiert, wenn die SSL-Aushandlung erfolgreich ist.

Hoffentlich sehen Sie einen Unterschied zwischen den beiden Client-Hallo-Nachrichten, mit denen Sie genau feststellen können, was mit der fehlgeschlagenen SSL-Aushandlung zu einem Fehlschlagen führt. Anschließend sollten Sie in der Lage sein, Konfigurationsänderungen an Windows vorzunehmen, damit diese erfolgreich durchgeführt werden können. IISCrypto ist ein großartiges Werkzeug dafür (auch für Client-PCs, trotz des "IIS" -Namens).

Die folgenden beiden 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 des Problems Could not create SSL/TLS secure channel untersucht und gelöst habe: http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error- in-windows.html

7
Jon Schneider

Handelt es sich bei dem Client um einen Windows-Computer, kann dies daran liegen, dass das vom Dienst benötigte 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

enter image description here

6
cnom

Ich habe den ganzen Tag mit diesem Problem gekämpft.

Als ich mit .NET 4.5 ein neues Projekt erstellt habe, hat es endlich funktioniert.

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

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

6
aghost

In meinem Fall hatte das Dienstkonto, unter dem die Anwendung ausgeführt wird, 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 zu persönlich
  4. zertifikat auswählen
  5. rechtsklick
  6. Alle Aufgaben
  7. Private Schlüssel verwalten
  8. Hinzufügen
5
Dinesh Rajan

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

<httpRuntime targetFramework="4.5.2" />

und nicht:

<httpRuntime targetFramework="4.6.1" />
5
Terje Solem

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

4
bplus

Ich hatte das gleiche Problem und stellte fest, dass diese Antwort für mich richtig funktionierte. Der Schlüssel ist 3072. Dieser Link liefert 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 das Update:

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

Die am häufigsten gewählte Antwort wird wahrscheinlich für die meisten Menschen ausreichen. Unter bestimmten Umständen kann der Fehler "SSL/TLS Secure Channel konnte nicht erstellt werden" auch nach dem Erzwingen von TLS 1.2 weiterhin angezeigt werden. In diesem Fall sollten Sie diesen hilfreichen Artikel zu weiteren Schritten zur Fehlerbehebung konsultieren. Zusammenfassend: Unabhängig von 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 die unterstützten Cipher-Suites auf, damit der Server sie mit seiner eigenen Liste vergleichen kann. Auf einigen Windows-Rechnern wurden jedoch möglicherweise bestimmte gängige Chiffresuiten deaktiviert (anscheinend aufgrund wohlmeinender Versuche, die Angriffsfläche einzuschränken), was die Wahrscheinlichkeit verringert, dass sich Client und Server auf eine Chiffresuite einigen. Wenn sie nicht übereinstimmen können, wird in der Ereignisanzeige möglicherweise "Schwerwiegender Warncode 40" und in Ihrem .NET-Programm "SSL/TLS-Sicherheitskanal konnte nicht erstellt werden" angezeigt.

In dem oben genannten Artikel wird erläutert, wie Sie alle potenziell unterstützten Cipher Suites eines Computers auflisten und zusätzliche Cipher Suites ü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 definitiveren 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 erreichbar). Es versteht sich von selbst, dass Änderungen an der Registrierung mit Vorsicht vorgenommen werden müssen , insbesondere bei Netzwerken. (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?)

In meinem Unternehmen haben wir über die Registrierungsbearbeitung mehrere zusätzliche "ECDHE_ECDSA" -Suiten 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-Datenverkehr an ein separates Programm Python delegieren (das möglicherweise selbst funktioniert, aus demselben Grund, aus dem Chrome Anforderungen möglicherweise erfolgreich sind, wenn MSIE-Anforderungen auf einem fehlschlagen betroffene Maschine).

3
APW

System.Net.WebException: Die Anforderung wurde abgebrochen: SSL/TLS-Sicherheitskanal konnte nicht erstellt werden.

In unserem Fall haben wir einen Softwarehersteller verwendet, sodass wir keinen Zugriff zum Ändern des .NET-Codes hatten. Anscheinend wird .NET 4 TLS v 1.2 nur verwenden, wenn eine Änderung vorliegt.

Das Update für uns war das Hinzufügen des Schlüssels SchUseStrongCrypto zur Registrierung. Sie können den folgenden Code kopieren, in eine Textdatei mit der Erweiterung .reg einfügen und ausführen. Es diente als "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
3
capdragon

Versuche dies:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
3
Muhammad Awais

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 das richtige Zertifikat Berechtigungen für das Zertifikat.

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

2
Danny Cullen

Diese Frage kann viele Antworten haben, da es sich um eine allgemeine Fehlermeldung handelt. Wir sind auf einigen unserer Server auf dieses Problem gestoßen, aber nicht auf unsere Entwicklungsmaschinen. Nachdem wir uns die Haare ausgezogen hatten, stellten wir fest, dass es sich um einen Microsoft-Fehler handelte.

https://support.Microsoft.com/de-de/help/4458166/applications-that-on-tls-1-2-strong-encryption-experience-connect

Grundsätzlich 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, sodass Sie die gefürchtete Meldung "Die Anforderung wurde abgebrochen: SSL/TLS-Sicherheitskanal konnte nicht erstellt werden." Erhalten.

Es gibt drei Fehlerbehebungen.

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 im Knowledge Base-Artikel erwähnt, den ich veröffentlicht habe.

2
Michael Silver

In meinem Fall hatte ich dieses Problem, als ein Windows-Dienst versuchte, eine Verbindung zu einem Webdienst herzustellen. Beim Durchsuchen von Windows-Ereignissen wurde schließlich ein Fehlercode gefunden.

Ereignis-ID 36888 (Schannel) wird ausgelöst:

The following fatal alert was generated: 40. The internal error state is 808.

Schließlich wurde es mit einem Windows-Hotfix in Verbindung gebracht. In meinem Fall: KB3172605 und KB3177186

Die vorgeschlagene Lösung im VMware-Forum war das Hinzufügen eines Registrierungseintrags in Windows. Nach dem Hinzufügen der folgenden Registrierung funktioniert alles einwandfrei.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman]

"ClientMinKeyBitLength" = dword: 00000200

Anscheinend hängt es mit einem fehlenden Wert im https-Handshake auf der Clientseite zusammen.

Listen Sie Ihr Windows HotFix auf:

wmic qfe list

Lösungs-Thread:

https://communities.vmware.com/message/2604912#2604912

Hoffe es hilft.

Dies geschah für mich nur auf einer Seite, und es stellte sich heraus, dass nur die RC4-Chiffre verfügbar war. In einem früheren Versuch, den Server abzusichern, hatte ich die RC4-Verschlüsselung deaktiviert, nachdem ich diese wieder aktiviert hatte, wurde das Problem behoben.

1
Mark Reid

Sie können versuchen, ein Demo-Zertifikat zu installieren (einige SSL-Anbieter bieten es einen Monat lang kostenlos an), um sicherzugehen, ob das Problem mit der Gültigkeit der Zertifikate zusammenhängt oder nicht.

1
twk

Vergewissern Sie sich zusätzlich zu den obigen Antworten, dass Sie das CER-Zertifikat und NICHT die PFX-Datei in Ihren lokalen Computerspeicher importiert haben. Ein häufiger Fehler, wenn Sie beide Dateien haben.

1
Carl Prothman

Solange dies ein relativ "lebender" Link ist, dachte ich, ich würde eine neue Option hinzufügen. Diese Möglichkeit besteht darin, dass der Dienst SSL 3.0 aufgrund des Problems mit dem Pudelangriff nicht mehr unterstützt. Lesen Sie hierzu die Google-Erklärung. Dieses Problem trat bei mehreren Webdiensten gleichzeitig auf und mir wurde klar, dass etwas los sein musste. Ich habe auf TLS 1.2 umgestellt und alles funktioniert wieder.

http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

1
Marcus Cole

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

1
jayasurya_j

Keine der Antworten hat für mich funktioniert.

Das hat funktioniert:

Anstatt meinen X509Certifiacte2 folgendermaßen zu initialisieren:

   var certificate = new X509Certificate2(bytes, pass);

Ich habe es so gemacht:

   var certificate = new X509Certificate2(bytes, pass, X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable);

Beachten Sie dieX509KeyStorageFlags.Exportable!!

Ich habe den Rest des Codes (das WebRequest selbst) nicht geändert:

// I'm not even sure the first two lines are necessary:
ServicePointManager.Expect100Continue = true; 
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

request = (HttpWebRequest)WebRequest.Create(string.Format("https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", server));
request.Method = "GET";
request.Referer = string.Format("https://Hercules.sii.cl/cgi_AUT2000/autInicio.cgi?referencia=https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", servidor);
request.UserAgent = "Mozilla/4.0";
request.ClientCertificates.Add(certificate);
request.CookieContainer = new CookieContainer();

using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
{
    // etc...
}

Tatsächlich bin ich mir nicht mal sicher, ob die ersten beiden Zeilen notwendig sind ...

1
sports

Das standardmäßige .NET ServicePointManager.SecurityProtocol verwendet SSLv3 und TLS. Wenn Sie auf einen Apache-Server zugreifen, gibt es eine Konfigurationsvariable mit dem Namen SSLProtocol, die standardmäßig TLSv1.2 verwendet. Sie können entweder den ServicePointManager.SecurityProtocol so einstellen, dass das von Ihrem Webserver unterstützte Protokoll verwendet wird, oder Sie können Ihre Apache-Konfiguration so ändern, dass alle Protokolle wie folgt zugelassen werden: SSLProtocolall.

0
Paul

Ich bin vor kurzem auf dasselbe Problem gestoßen. Meine Umgebung läuft unter .NET 4.6.1 mit VB.NET. So habe ich es behoben:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3
ServicePointManager.ServerCertificateValidationCallback = New RemoteCertificateValidationCallback(AddressOf util.ValidateServerCertificate)

und die util.ValidateServerCertificate-Funktion ist:

Public Function ValidateServerCertificate(ByVal sender As Object, ByVal certificate As X509Certificate, ByVal chain As X509Chain, ByVal sslPolicyErrors As SslPolicyErrors) As Boolean
    Return True
End Function
0
cavalcanteg

Wenn Sie Ihren Code nicht möchten, nicht einfach oder nicht schnell patchen können, können Sie stattdessen die Verwendung von TLS 1.2 durch Ihren .NET-Code im Framework erzwingen.

Dies ist nicht meine App, aber es hat dazu beigetragen, dass unsere ältere .NET 4.5-App (auf Server 2008r2) wieder mit Paypal Payflow Gateway funktioniert. Sie müssen zwischen dem 25.06.18 und dem 08.07.18 damit begonnen haben, Verbindungen zu TLS 1.2 für die Rückrufe des Payflow-Gateways zu erzwingen.

Details: https://github.com/TheLevelUp/pos-tls-patcher Download: https://github.com/TheLevelUp/pos-tls-patcher/releases

0
cvocvo

Ich hatte Cert im Laden und in der Akte. Ich habe versucht, eine Verbindung mit der Datei herzustellen, und diese Fehlermeldung erhalten. Als ich das im Laden benutzte, funktionierte es. Ich vermute, dass es zu Konflikten gekommen ist, weil das Zertifikat auf Lager war, als ich das in der Akte befindliche verwenden wollte. (Ein anderer Dienst auf demselben Computer verwendete das Zertifikat im Geschäft, und ich hatte einen anderen Dienst mit dem in der Datei gespeicherten Zertifikat entwickelt. Funktionierte bis zum Test wie ein Zauber auf dem Entwickler.).

0
Jon