Ich versuche C # -Code zu schreiben, der eine Webanforderung an einen REST-Dienstendpunkt stellt, der für die Berechnung der Mehrwertsteuer in einer Webanwendung verwendet wird. Dies ist ein Service von Drittanbietern, und es ist mit SSL gesichert. Es gibt zwei Umgebungen, UAT und Produktion. Der Code, der die Webanforderung ausführt, sieht folgendermaßen aus:
%Vor%Dies funktioniert gut gegen die UAT-Umgebung. Aber wenn ich denselben Code für die Produktionsumgebung ausfühle, bekomme ich den Fehler:
"SSL / TLS sicherer Kanal konnte nicht erstellt werden"
Ich bin in der Lage, beide Anfragen von Postman ohne Problem ohne spezielle Modifikationen auszuführen.
Dies führte mich auf den Weg, diesen Fehler zu untersuchen, und ich fand viele hilfreiche SO-Beiträge, die das Thema diskutierten, einschließlich:
Die Anfrage wurde abgebrochen: Konnte nicht Erstellen Sie einen sicheren SSL / TLS-Kanal
Diese Funktionen halfen mir, indem Sie mich in die richtige Richtung wiesen. Dabei wurde die Einstellung ServicePointManager.SecurityProtocol auf einen anderen Wert gesetzt und mithilfe von ServicePointManager.ServerCertificateValidationCallback Fehler untersucht.
Was ich nach dem Spielen mit diesen gefunden habe, ist folgendes:
Dieser Code sieht so aus:
%Vor%Das ist besonders verwirrend, weil ich beim Betrachten der Endpunkte in einem Webbrowser sehen kann, dass beide mit demselben Platzhalterzertifikat gesichert sind und beide TLS 1.0 verwenden.
Ich würde also erwarten, dass das Setzen von ServicePointManager.SecurityProtocol auf TLS funktionieren würde, aber nicht.
Ich möchte wirklich vermeiden, ServicePointManager.SecurityProtocol explizit auf SSL3 zu setzen, da unsere Anwendung eine Webanwendung ist und mehrere andere Integrationspunkte hat, die über SSL kommunizieren. Diese funktionieren alle gut und ich möchte ihre Funktionalität nicht beeinträchtigen. Selbst wenn ich diese Einstellung direkt vor dem Anruf einstelle und sie dann gleich wieder zurückstelle, riskiere ich, Probleme mit Nebenläufigkeit zu bekommen, da ServicePointManager.SecurityProtocol statisch ist.
Ich habe auch dieses Thema untersucht und mochte nicht, was ich gelesen habe. Es gibt Hinweise auf die Verwendung verschiedener App-Domains:
.NET https-Anfragen mit unterschiedlichen Sicherheitsprotokollen über Threads
Wie zu verwenden SSL3 anstelle von TLS in einer bestimmten HttpWebRequest?
Aber das scheint mir zu komplex / hacky zu sein. Ist das Erstellen einer App-Domain wirklich die einzige Lösung? Oder sollte ich das nicht einfach lösen und stattdessen mit dem Eigentümer des betreffenden Dienstes aufnehmen? Es ist sehr interessant für mich, dass es mit TLS auf einer Umgebung / Server funktioniert, aber nicht mit der anderen.
BEARBEITEN Ich habe mehr damit gespielt. Ich habe meinen Client geändert, um den in diesem Blogpost beschriebenen Ansatz zu verwenden (mithilfe einer anderen App-Domäne den Code zu isolieren, der das ServicePointManager.SecurityProtocol ändert):
Das hat wirklich gut funktioniert und könnte eine Lösung sein. Aber ich habe auch erfahren, dass der Anbieter des betreffenden Dienstes einen anderen Endpunkt (dieselbe URL, anderer Port) hat, der mit TLS 1.2 gesichert ist. Zum Glück, indem ich meine SecurityProtocol-Einstellung wie im Startup-Ereignis global.asax.cs erweitert:
%Vor%Ich kann mit dem Service in allen Umgebungen kommunizieren. Meine bestehenden Integrationen mit anderen Diensten (z. B. CyberSource) werden dadurch nicht beeinträchtigt.
Allerdings - jetzt gibt es eine neue, aber verwandte Frage. Warum funktioniert dieser Aufruf NUR, wenn ich SecurityProtocolType wie oben beschrieben erweitere? Meine anderen Integrationen, wie CyberSource, erforderten dies nicht. Aber das tut es. Und alle scheinen mit TLS 1.2 gesichert zu sein, was ich im Browser gesehen habe.
Einige der erweiterten TLS-Konfigurationen auf einem Webserver sind ausgeblendet. Ihr Produktionsserver wurde wahrscheinlich zum Schutz vor DROWN-, Logjam-, FREAK-, POODLE- und BEAST-Angriffen geändert.
siehe
Um Änderungen an diesen erweiterten TLS-Einstellungen vorzunehmen, müssen Sie nicht einfach auf einige Schaltflächen in IIS klicken. Nun, es könnte so einfach sein, wenn Sie ein Tool eines Drittanbieters wie folgt verwenden: Ссылка
Diese Konfigurationen funktionieren gut für die letzten großen Webbrowser, aber .Net scheint mit solchen modernen sicheren Serverkonfigurationen zu kämpfen (es sei denn, Sie überschreiben manuell die Standardeinstellungen, wie Sie entdeckt haben).
Fazit: Es ist nicht offensichtlich, Ihre UAT- und Produktionsumgebungen scheinen gleich zu sein, aber sie sind es nicht.
Wenn Sie 4.0 ausführen, können Sie es wie folgt verwenden:
%Vor%