wake-up-neo.com

Bei der Unterstützung für sichere Kanäle ist ein Fehler aufgetreten - Classic ASP HTTP Request

Ich habe eine klassische ASP Website auf einem Windows Server 2012-Computer. Auf einer Seite wird eine HTTP-Anfrage an eine andere Anwendung über https mit folgendem Code gesendet:

Sub ShopXML4http(url, inStr, outStr, method, xmlerror)
  Dim objhttp
  Set objhttp = Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0")
  objHttp.open method, url, false
  If Method="POST" Then
    objHttp.Send instr
  Else
    objHttp.Send
  End if   
  outstr=objHttp.responseText
  Set objhttp=nothing
End Sub

Dieser Code funktioniert fast immer einwandfrei (Tausende von Anfragen pro Tag), schlägt jedoch sporadisch mit einer Meldung wie der folgenden fehl:

Nummer: -2147012739

Beschreibung: In der Unterstützung für sichere Kanäle ist ein Fehler aufgetreten

Quelle: msxml6.dll

Die Anwendung wurde kürzlich von einem alten Windows 2003 Server auf den 2012 Server verschoben, und dieses Problem schien auf dem alten Server nie ein Problem zu sein. Während dieser Fehler auf der Website auftritt, kann ich in einem VBScript genau denselben Code ausführen, und er funktioniert einwandfrei. Das Zurücksetzen des Anwendungspools scheint dazu zu führen, dass die Site die sicheren HTTP-Anforderungen erneut ausführen kann (obwohl es sich häufig von selbst behebt, bevor ich auf den Server zugreifen kann).

30
Mike S

Ich hatte nach der Migration von 2003 auf 2008 R2 genau das gleiche Problem und fand die Lösung. Veränderung:

Set objhttp = Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0")

zu:

Set objhttp = Server.CreateObject ("MSXML2.XMLHTTP.6.0")

und dein Problem wird verschwinden.

Ich habe versucht, die Vor- und Nachteile beider Objekte zu finden, aber noch keinen Grund gefunden, XMLHTTP nicht zu verwenden.

17
user3087157

Ich hatte das gleiche Problem und habe viele Lösungen ausprobiert, die unter verschiedenen Beiträgen angeboten wurden, hatte aber bis jetzt keinen Erfolg. Ich werde die Lösung, die für mich funktioniert hat, unter Bezugnahme auf das Problem genau beschreiben, da es sich in meinem Fall um Paypal handelte. Ich habe keinen neuen Beitrag eröffnet, da dies in Zukunft möglicherweise nicht mehr nur ein Paypal-Problem ist.

Die Lösung ist eine Kombination aus mehreren von Stackoverflow bereitgestellten Lösungen für ähnliche Probleme, aber dies schien die beste Lösung zu sein.

Das Problem

Beim Versuch, Paypal IPN unter Windows Server 2008 mit der klassischen ASP mit der Paypal Sandbox zu testen, wird der Fehler "Ein Fehler bei der Unterstützung für sichere Kanäle ist aufgetreten" zurückgegeben.

Warum ist es ein Problem

Paypal verlangt, dass die gesamte Kommunikation mit ihren Systemen so sicher wie möglich ist. Sie benötigen eine Verbindung mit TLS 1.2. Windows Server 2008 ist standardmäßig nicht TLS 1.2.

Paypal warf einige Verwirrung in die Mischung, indem es sagte, dass Sie ein Verisign G5-Zertifikat benötigen, das Sie für den Server-Stamm, aber nicht für die Domain, auf der Sie Ihren Code ausführen, tun. Ich habe auch keine Paypal-Zertifikate installiert, da ich die API nicht verwende. Ich glaube nicht, dass Sie Ihre Kommunikation von einer HTTPS-Site benötigen - obwohl meine Domain mit einem GoDaddy EV-Standardzertifikat gesichert ist, obwohl ich danach einen Test auf einer Nicht-HTTPS-Site durchgeführt habe und das auch funktioniert hat.

Meine Lösung

  1. Überprüfen Sie zunächst mit SSL Labs , welche Art von Sicherheit Ihr Server verwendet. Es sollte TLS1.2 oder höher sein und keine anderen TLSs oder SSLs. Es muss auch eine SHA256-Verschlüsselung haben. Möglicherweise müssen Sie den Server patchen: https://support.Microsoft.com/en-us/kb/3106991 .

  2. Verwenden Sie IISCrypto, um das richtige TLS und die richtigen Chiffren festzulegen . Ich habe die Registrierungsänderungen verwendet, die auf stackoverflow an anderer Stelle angeboten wurden, aber dies hat nicht funktioniert und tatsächlich meinen Server für alles, was HTTPS-Posts verwendet, total vermasselt, nicht nur für meine Entwicklungssite! IISCrypto behandelt auch die Chiffren.

  3. Vergewissern Sie sich, dass Ihr Anwendungspool die Version 4.5 aufweist, was an sich unklar ist, da IIS möglicherweise nur die Version 4.0 anbietet Dies ist jedoch wahrscheinlich Version 4.5. Sie können dies über https://msdn.Microsoft.com/en-us/library/hh925568 (v = vs.110) .aspx überprüfen =.

  4. In Ihrem Code müssen Sie Server.CreateObject ("MSXML2.XMLHTTP.6.0") verwenden, nicht Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0"), wie oben erwähnt.

Jetzt habe ich keine Ahnung, warum das Nicht-Server-XMLHTTP so funktioniert, wie es der Dokumentation dahinter zu widersprechen scheint. Im Moment ist es mir nach 10 Tagen Stress, Panik und Frustration egal! Ich hoffe, das ist nützlich für andere.

Die Lösung zu finden war ein Albtraum, daher füge ich unten einige Ausdrücke hinzu, um anderen bei der Suche zu helfen:

Paypal IPN schlägt mit Serverfehler fehl

Paypal SSL Windows 2008 Fehler

In der Secure Channel-Unterstützung ist ein Fehler aufgetreten

klassische ASP Paypal Sandbox SSL-Fehler

Ich möchte Rackspace und GoDaddy öffentlich für ihre Hilfe danken. Ich möchte öffentlich mitteilen, dass Paypal den schlechtesten technischen Support aller Zeiten bietet und es mir einfach egal ist, ständig auf ihre eigenen Dokumente zu verweisen, falls sie jemals antworten. Sie sagen, dass sie seit September 2014 E-Mails darüber verschicken, aber ich habe nie eine erhalten. Diese neuen Anforderungen sind auf der Paypal-Sandbox aktiv, werden jedoch im September 2016 in Betrieb genommen. Ich bin nur auf die Entwicklung einer neuen Lösung gestoßen, die die Sandbox benötigte. Wenn Sie in Betrieb sind, werden Sie das Problem erst dann kennen, wenn sie auftritt Du bist tot im Wasser. Testen Sie Ihr gesamtes Zahlungssystem so schnell wie möglich auf der Paypal-Sandbox!

7
Steve Neale

Keine der obigen Antworten trifft auf meine Situation zu. Dann bin ich auf den Link hier gesprungen:

https://support.Microsoft.com/en-za/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-) Protokolleingabe

Dieses Update bietet Unterstützung für Transport Layer Security (TLS) 1.1 und TLS 1.2 in Windows Server 2012, Windows 7 Service Pack 1 (SP1) und Windows Server 2008 R2 SP1.

Anwendungen und Dienste, die mithilfe von WinHTTP für SSL-Verbindungen (Secure Sockets Layer) erstellt wurden und das WINHTTP_OPTION_SECURE_PROTOCOLS-Flag verwenden, können die Protokolle TLS 1.1 oder TLS 1.2 nicht verwenden. Dies liegt daran, dass die Definition dieses Flags diese Anwendungen und Dienste nicht enthält.

Mit diesem Update wird der Registrierungseintrag DefaultSecureProtocols unterstützt, mit dem der Systemadministrator angeben kann, welche SSL-Protokolle verwendet werden sollen, wenn das WINHTTP_OPTION_SECURE_PROTOCOLS-Flag verwendet wird.

Dadurch können bestimmte Anwendungen, die für die Verwendung des WinHTTP-Standardflags erstellt wurden, die neueren TLS 1.2- oder TLS 1.1-Protokolle nativ nutzen, ohne dass die Anwendung aktualisiert werden muss.

Dies ist bei einigen Microsoft Office-Anwendungen der Fall, wenn sie Dokumente aus einer SharePoint-Bibliothek oder einem Webordner, IP-HTTPS-Tunnel für DirectAccess-Konnektivität und andere Anwendungen mithilfe von Technologien wie WebClient mithilfe von WebDav, WinRM und öffnen andere.

Dieses Update ändert nicht das Verhalten von Anwendungen, die die sicheren Protokolle manuell festlegen, anstatt das Standardflag zu übergeben.

Client service Auf dem Windows 2008 R2 - Server, der über TLS an den Server gesendet wurde, hat den fraglichen Fehler behoben. Ich dachte, es könnte sich um die Kompatibilität mit der Chiffre Suite handeln. Wireshark Die in der Client Hello - Anfrage angegebene Version war TLS 1.0, der Server benötigt jedoch TLS 1.2. Die vom Clientdienst an den Ausgangsserver gesendeten Cipher Suites waren in Ordnung. Das Problem ist, dass der Clientdienst oder die Anwendung auf dem Windows-Server standardmäßig den Systemstandard verwendet, der nicht TLS 1.2 ist.

Die Lösung besteht darin, einen Registrierungsunterschlüssel mit dem Namen DefaultSecureProtocols mit einem Wert hinzuzufügen, der der TLS-Version (en) entspricht, die unterstützt werden sollen. Fügen Sie den Registrierungsunterschlüssel mit dem Typ DWORD den folgenden Positionen hinzu:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
  • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\Aktuelle Version\Interneteinstellungen\WinHttp

Für Internet Explorer Fix können Sie einen ähnlichen Registrierungsunterschlüssel mit dem Titel SecureProtocols, ebenfalls mit dem Typ DWORD, an den folgenden Speicherorten hinzufügen:

  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings

Unten finden Sie die Wertetabelle für beide Unterschlüssel:

DefaultSecureProtocols Value         Protocol enabled
0x00000008                           Enable SSL 2.0 by default
0x00000020                           Enable SSL 3.0 by default
0x00000080                           Enable TLS 1.0 by default
0x00000200                           Enable TLS 1.1 by default
0x00000800                           Enable TLS 1.2 by default

Zum Beispiel:

Der Administrator möchte die Standardwerte für WINHTTP_OPTION_SECURE_PROTOCOLS überschreiben, um TLS 1.1 und TLS 1.2 anzugeben.

Nehmen Sie den Wert für TLS 1.1 (0x00000200) und den Wert für TLS 1.2 (0x00000800) und addieren Sie sie im Taschenrechner (im Programmiermodus). Der resultierende Registrierungswert wäre 0x00000A00.

Ich habe 0x00000A00 als Wert für beide Unterschlüssel angewendet und das Problem erfolgreich behoben.

Es gibt auch ein Easy Fix (Link ist hier: https://aka.ms/easyfix51044 ) von Microsoft, Wenn Sie Registrierungsunterschlüssel und -werte nicht manuell eingeben möchten.

3
user3621633

Fehlerbehebung bei Fehlercodes:

  1. -2147012739 ist ein HRESULT.
  2. Hexadezimal ist das 0x80072F7D.
  3. Schau dir das LOWORD an: 0x2F7D.
  4. Konvertieren Sie das zurück in Dezimalzahl: 12157.
  5. 12157 Fehlercodes suchen.
  6. Finden Sie, dass es passt: ERROR_WINHTTP_SECURE_CHANNEL_ERROR

Ein bisschen Google-fu findet http://msdn.Microsoft.com/en-us/library/windows/desktop/aa383770 (v = vs.85) .aspx das besagt:

ERROR_WINHTTP_SECURE_CHANNEL_ERROR

12157

Zeigt an, dass ein Fehler im Zusammenhang mit einem sicheren Kanal aufgetreten ist (entspricht Fehlercodes, die mit "SEC_E_" und "SEC_I_" beginnen und in der Header-Datei "winerror.h" aufgeführt sind).

Sie haben dies jedoch bereits festgestellt, als Sie die Meldung "Beschreibung: In der Unterstützung für sichere Kanäle ist ein Fehler aufgetreten" erhielten. Das führt uns also wieder dorthin, wo wir angefangen haben.

Die andere Beobachtung, die ich mache, ist, dass Ihr Code eine nicht asynchrone WinHTTP-Anforderung ist (ich weiß, dass es innerhalb von ASP funktionieren muss), aber die Sorge ist, dass Ihr Computer aufgrund der hohen Häufigkeit mehr als ein WinHTTP verarbeiten könnte gleichzeitig anfordern. Ich habe gesehen, dass einige Windows absichtlich die Gesamtzahl der aktiven gleichzeitigen WinHTTP-Anforderungen drosselten, indem sie die verspäteten Anforderungen blockierten. Beispielsweise kann ein Prozess auf einem Windows 7-Computer nicht mehr als zwei gleichzeitige Anforderungen an denselben Remoteserver senden. d.h. die 3., 4. ... Anforderung wird blockiert, bis die ersten beiden abgeschlossen sind.

Eine Lösung besteht darin, eingehende Anforderungen über mehrere Anwendungspools oder über mehrere Server zu verteilen.

2
Stephen Quan

Wir hatten eine Variation zu diesem Thema und es hat uns einige Zeit gekostet, es herauszufinden.
Hier ist die Situation: Ein älterer Linux-Server, der eine in PHP) geschriebene Anwendung hostet und Daten über Webservice-Aufrufe bereitstellt. Der Server verwendet HTTPS. Aufrufe von verschiedenen Clients erfolgen mit Code Verwenden der winHTTP 5.2-Bibliothek. (Winhttp.dll)

Symptom: Unsere Clients erhalten jetzt sporadische Fehlermeldungen, wenn sie wiederholte winHTTP-Aufrufe mit einem POST-Befehl ausführen. Die Meldungen lauten entweder "Die an eine Funktion gelieferten Puffer waren zu klein" oder "Es ist ein Fehler in der Unterstützung für sichere Kanäle aufgetreten". Nach langem Suchen stellten wir fest, dass der Server des Clients in der Ereignisanzeige den Warncode 20 (Schannel Event ID 36887) protokollierte, der der sichtbaren Fehlermeldung entsprach.

Lösung: Wir haben festgestellt, dass unser alter Linux-Server TLS 1.2 nicht unterstützen kann. (CentOS 5.11) Wir haben auch erfahren, dass einige unserer Kunden kürzlich (Sommer 2016) ein Update auf ihre Microsoft-Server angewendet haben. (Server 2008, Server 2012) Der Fix bestand darin, die Server zu zwingen, TLS 1.1 für die Webservice-Aufrufe zu verwenden. Das für mich eher seltsame ist, dass die Einstellungen im Internet Explorer zum Ändern des TLS keinen Einfluss auf das Problem hatten. Durch Ändern einer Einstellung in den Gruppenrichtlinien konnten wir das Problem jedoch lösen. Unser technischer Berater in dieser Angelegenheit wies darauf hin, dass die Änderung wirklich unklar ist, dass jedoch ein Drittanbieter eine schnelle Lösung bereitgestellt hat. Dieses Tool heißt IIS Crypto von Nartac. https://www.nartac.com/Products/IISCrypto/Download Mit diesem Tool können Sie speziell Protokolle auswählen Jetzt einen neuen Server zum Hosten unserer Anwendungen (CentOS 6) bekommen und sollte dann das TLS 1.2-Protokoll verwenden können!

2
Tom Fahey

Es ist alles gültig, aber das "kritische" fehlende Bit für die TLS1.2-Unterstützung unter Windows 7 mit IIS7.5 und klassischem ASP setzt dies in der Registrierung:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000800

Ich hoffe, das erspart Ihnen einen Tag voller Faffing, Neustart und Kopfkratzen! :)

Dieses Code-Snippet ist nützlich zum Testen. https://www.howsmyssl.com/

<%
Set winhttp = Server.CreateObject("WinHTTP.WinHTTPRequest.5.1")
winhttp.open "GET", "https://howsmyssl.com/a/check", False
winhttp.Send
Response.Write winhttp.responseText 
%>
2
Gruff

In einem Windows Server 2016 Classic ASP Skript, das eine HTTPS-URL von Windows Server 2012 R2 abruft, musste ich kürzlich SSL 2.0 von SecureProtocols entfernen, um diesen Secure Channel-Fehler -2147012739 zu beenden.

' Use the latest client
Set httpClient = Server.CreateObject("WinHttp.WinHttpRequest.5.1")

' allow only TLS 1.2 or TLS 1.1
Const WHR_SecureProtocols = 9
httpClient.Option(WHR_SecureProtocols) = &h0800 + &h0200 
' Other values: TLS 1.0 &h0080, SSL 3.0 &h0020, SSL 2.0 &h0008 
' NB Including SSL 2.0 stops https to Windows Server 2012 R2 working

' Other options you may want to set, from https://docs.Microsoft.com/en-us/windows/desktop/winhttp/winhttprequestoption 

' Ignore certificate errors
Const WHR_SslErrorIgnoreFlags = 4
httpClient.Option(WHR_SslErrorIgnoreFlags) = &h3300 

' Don't bother checking cert, or risking failure if we can't check
Const WHR_EnableCertificateRevocationCheck = 18
httpClient.Option(WHR_EnableCertificateRevocationCheck) = False 
1
stevek_mcc

Ich selbst bin vor ein paar Monaten auf diesen Fehler gestoßen. In den meisten Fällen wird dieses Problem durch ein ungültiges SSL-Zertifikat verursacht. In Anbetracht der Tatsache, dass Sie zum Zeitpunkt des Posts gerade auf einen neuen Server migriert waren, müssen Sie wahrscheinlich nur das SSL-Zertifikat neu installieren.

Mir ist klar, dass diese Frage alt ist, aber hoffentlich kann jemand anderes von meiner Antwort profitieren.

0
coderpro