A apărut o eroare în cadrul suportului pentru canalul securizat – Solicitare ASP HTTP clasică (Programare, Iis, Asp Clasic, Xmlhttprequest, Windows Server 2012)

Mike S a intrebat.

Am un site web ASP clasic care rulează pe o cutie Windows Server 2012. O pagină face o cerere HTTP către o altă aplicație prin https folosind un cod ca acesta:

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

Acest cod funcționează bine aproape tot timpul (mii de cereri pe zi), dar sporadic va eșua cu un mesaj de genul acesta:

Număr: -2147012739

Descriere: A apărut o eroare în suportul canalului securizat

Sursă: msxml6.dll

Aplicația a fost mutată recent de pe un vechi server Windows 2003 pe serverul 2012, iar această problemă nu părea să fi fost niciodată o problemă pe vechiul server. În plus, în timp ce această eroare se întâmplă pe site-ul web, aș putea rula exact același cod într-un VBScript și funcționează bine. Resetarea pool-ului de aplicații pare să facă ca site-ul să poată face din nou solicitările HTTP securizate (deși adesea se remediază singur înainte ca eu să pot ajunge la server).

Comentarii

  • Am reușit să verific că, pe același pool de aplicații, am reușit să efectuez cu succes exact aceeași cerere într-un code-behind de pagină ASP.NET, în timp ce în pagina ASP clasică dădea eroare. –  > Por Mike S.
  • Tocmai am încercat să convertesc pagina ASP clasică din obiectul MSXML2.ServerXMLHTTP în WinHttp.WinHttpRequest.5.1. Din nou, aceasta funcționează bine pentru multe cereri, dar în cele din urmă a primit și eroarea de suport pentru canalul securizat. –  > Por Mike S.
  • Acum am schimbat site-ul din modul integrat în modul clasic pentru ca acesta să funcționeze mai mult ca IIS 6. În continuare, problema a apărut de cel puțin două ori în ultimele 24 de ore. –  > Por Mike S.
  • Presupun că este vorba de o problemă de rețea la un nivel mai jos de HTTP(S). Vizualizați jurnalul de evenimente System, Application și Security pe ambele servere. De asemenea, dacă este posibil, modificați scriptul dvs. pentru scrierea fișierului txt cel mai simplu, cu „start time” (înainte de open method) și „stop time” (după send metodă). Observați diferența de timp atunci când serviciul eșuează. De asemenea, încercați să apelați setOption metoda cu valoarea SXH_OPTION_IGNORE_SERVER_SSL_CERT_ERROR_FLAGS – nu cred că vă poate ajuta, dar încercați. –  > Por VMV.
  • Cererea pe care o trimiteți se referă la același server pe care rulează scriptul? –  > Por gpinkas.
8 răspunsuri
user3087157

Am avut exact aceeași problemă după ce am migrat de la 2003 la 2008 R2 și am găsit soluția. Schimbare:

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

în:

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

și problema ta va dispărea.

Am încercat să găsesc argumente pro și contra despre ambele obiecte, dar nu am găsit încă un motiv pentru a nu folosi XMLHTTP.

Comentarii

  • „MSXML2.XMLHTTP.6.0” nu acceptă metoda „waitForResponse”. Acesta este un dezavantaj. –  > Por Matija.
Steve Neale

Am avut aceeași problemă și eu și am încercat o mulțime de soluții oferite sub o varietate de mesaje, dar în cele din urmă nu am avut succes, până acum. Voi detalia soluția care a funcționat pentru mine cu referire la problemă, deoarece în cazul meu a fost PayPal. Nu am deschis un post nou deoarece s-ar putea ca pe viitor să nu fie doar o problemă legată de PayPal.

Soluția este o combinație a mai multor soluții postate pe stackoverflow la probleme similare, dar aceasta mi s-a părut cea mai bună pentru a o adăuga.

Problema

Încercarea de a testa PayPal IPN pe Windows Server 2008 folosind ASP clasic folosind PayPal Sandbox returnează eroarea „A apărut o eroare în suportul canalului securizat”.

De ce este o problemă

PayPal cere ca toate comunicațiile cu sistemele sale să fie cât mai sigure posibil. Veți avea nevoie de o conexiune care să fie TLS 1.2. Windows Server 2008 nu este TLS 1.2 în mod implicit.

PayPal a aruncat puțină confuzie în amestec spunând că aveți nevoie de un certificat Verisign G5, ceea ce este necesar pentru rădăcina serverului, dar nu și pentru domeniul pe care executați codul. De asemenea, nu am instalat niciun certificat PayPal, deoarece nu folosesc API-ul. Nu cred că aveți nevoie nici de comunicațiile de pe un site HTTPS – deși domeniul meu este securizat folosind un certificat standard GoDaddy EV, deși am făcut un test pe un site care nu este HTTPS după aceea și a funcționat și acesta.

Soluția mea

  1. Verificați mai întâi ce tip de securitate folosește serverul dvs. prin intermediul SSL Labs.Acesta ar trebui să fie TLS1.2 sau mai mare. și să nu existe alte TLS sau SSL. De asemenea, trebuie să aibă o criptare SHA256.Este posibil să fie nevoie să aplicați un patch serverului: https://support.microsoft.com/en-us/kb/3106991.

  2. Utilizați IISCrypto pentru a seta TLS și cifrele corecte.. Am folosit modificările de registru oferite în altă parte pe stackoverflow, dar acest lucru nu a funcționat și, de fapt, mi-a stricat complet serverul pentru tot ceea ce folosea mesaje HTTPS, nu doar pentru site-ul meu de dezvoltare! IISCrypto se ocupă, de asemenea, de cifre.

  3. Asigurați-vă că pool-ul de aplicații este v4.5, , ceea ce în sine este neclar, deoarece IIS ar putea oferi doar v4.0 ca opțiune. Cu toate acestea, probabil că este de fapt v4.5. Puteți verifica acest lucru prin https://msdn.microsoft.com/en-us/library/hh925568(v=vs.110).aspx.

  4. În cadrul codului dvs. trebuie să utilizați Server.CreateObject ("MSXML2.XMLHTTP.6.0"), , nu Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0") așa cum s-a menționat mai sus.

Acum nu am nicio idee de ce XMLHTTP non-server funcționează, deoarece pare să fie contrar documentației din spatele acestuia. În acest moment, după 10 zile de stres, panică și frustrare nu-mi pasă! Sper că acest lucru este util pentru alții.

Găsirea soluției a fost un coșmar, așa că voi adăuga câteva fraze mai jos pentru a-i ajuta pe alții în căutare:

PayPal IPN eșuează cu eroare de server

Erori PayPal SSL Windows 2008

A apărut o eroare în suportul canalului securizat

Erori clasice ASP PayPal Sandbox SSL clasice

Aș dori să le mulțumesc public lui Rackspace și GoDaddy pentru ajutorul lor în acest caz. Aș dori să declar în mod public că am constatat că paypal au cel mai rău suport tehnic vreodată și pur și simplu nu le pasă, arătând în mod constant la propriile lor documente, dacă răspund vreodată. Ei spun că au fost trimiterea de e-mailuri despre acest lucru din septembrie 2014, dar nu am primit niciodată unul. Aceste noi cerințe sunt active pe PayPal Sandbox, dar intră în vigoare în septembrie 2016. Am dat peste asta doar pentru că am dezvoltat o nouă soluție, așa că am avut nevoie de sandbox – dacă rulezi live, nu vei ști despre problemă până când nu apare și atunci ești mort în apă. Testați-vă întregul sistem de plată pe sandbox-ul PayPal cât mai curând posibil, este sfatul meu!!!

user3621633

Nici unul dintre răspunsurile de mai sus nu se aplică situației mele. Apoi am sărit pe link-ul de aici:

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

Această actualizare oferă suport pentru Transport Layer Security (TLS) 1.1 și TLS 1.2 în Windows Server 2012, Windows 7 Service Pack 1 (SP1) și Windows Server 2008 R2 SP1.

Aplicațiile și serviciile care sunt scrise prin utilizarea WinHTTP pentru conexiuni Secure Sockets Layer (SSL) care utilizează indicatorul WINHTTP_OPTION_SECURE_PROTOCOLS nu pot utiliza protocoalele TLS 1.1 sau TLS 1.2. Acest lucru se datorează faptului că definiția acestui indicator nu include aceste aplicații și servicii.

Această actualizare adaugă suport pentru intrarea de registru DefaultSecureProtocols, care permite administratorului de sistem să specifice ce protocoale SSL ar trebui să fie utilizate atunci când se utilizează marcajul WINHTTP_OPTION_SECURE_PROTOCOLS.

Acest lucru poate permite anumitor aplicații care au fost construite pentru a utiliza indicatorul implicit WinHTTP să poată utiliza protocoalele mai noi TLS 1.2 sau TLS 1.1 în mod nativ, fără a fi nevoie de actualizări ale aplicației.

Acesta este cazul unor aplicații Microsoft Office atunci când deschid documente dintr-o bibliotecă SharePoint sau un dosar web, tuneluri IP-HTTPS pentru conectivitate DirectAccess și alte aplicații prin utilizarea unor tehnologii precum WebClient prin utilizarea WebDav, WinRM și altele.

Această actualizare nu va schimba comportamentul aplicațiilor care setează manual protocoalele securizate în loc să treacă indicatorul implicit.

Client service pe Windows 2008 R2 serverul de ieșire către server prin TLS a reciprocat eroarea în cauză. M-am gândit că ar putea fi vorba de compatibilitatea suitei de cifru. Wireshark Trace a indicat versiunea în Client Hello cerere era TLS 1.0, dar serverul necesită TLS 1.2. Suitele de cifrare trimise către serverul de ieșire de la serviciul client erau în regulă. Problema este că serviciul client sau aplicația de pe serverul Windows utilizează în mod implicit serviciul implicit al sistemului, care nu este TLS 1.2.

Soluția constă în adăugarea unei subchei în registru numită DefaultSecureProtocols cu o valoare care să corespundă versiunii (versiunilor) TLS care ar trebui să fie acceptate. Adăugați respectiva subcheie de registru, cu tipul DWORD, , în următoarele locații:

  • HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsWinHttp
  • HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionInternet SettingsWinHttp

Pentru remedierea Internet Explorer, puteți adăuga o subcheie de registru similară intitulată SecureProtocols, , tot cu tipul DWORD, , în următoarele locații:

  • HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet Settings
  • HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet Settings

Mai jos puteți găsi tabelul cu valorile pentru ambele subclave:

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

De exemplu:

Administratorul dorește să suprascrie valorile implicite pentru WINHTTP_OPTION_SECURE_PROTOCOLS pentru a specifica TLS 1.1 și TLS 1.2.

Luați valoarea pentru TLS 1.1 (0x00000200200) și valoarea pentru TLS 1.2 (0x00000800), apoi adăugați-le împreună în calculator (în modul programator), valoarea de registru rezultată va fi 0x00000A00.

Am aplicat 0x00000A00 ca valoare pentru ambele subclave și a rezolvat cu succes problema.

Există, de asemenea, un Soluție ușoară (linkul este aici: https://aka.ms/easyfix51044) disponibilă de la Microsoft, dacă nu doriți să introduceți manual subclavele și valorile din registru.

Comentarii

  • Pe Windows 7, acest Easy Fix funcționează foarte bine chiar și cu MSXML2.ServerXMLHTTP.6.0 (nu este nevoie să treceți la MSXML2.XMLHTTP.6.0). Trebuie să reporniți mașina după ce îl instalați. –  > Por user1408140.
  • Există o întrebare separată care se referă la modul de setare a setării registrului. Am recomandat să o verificați. Este un one-liner pe linia de comandă și pot confirma că funcționează. superuser.com/questions/1080317/… –  > Por Christiaan Westerbeek.
Gruff

Totul este valabil, însă partea „critică” care lipsește pentru suportul TLS1.2 pe Windows 7 cu IIS7.5 și asp clasic este setarea acestui lucru în registru:-

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsWinHttp]
"DefaultSecureProtocols"=dword:00000800

Sper că asta vă scutește de o zi de zăpăceală, repornire și de zgârieturi în cap! 🙂

Acest fragment de cod este util pentru testare. 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 
%>

stevek_mcc

Într-un script ASP clasic Windows Server 2016, care preia un URL HTTPS de la Windows Server 2012 R2, a trebuit recent să elimin SSL 2.0 din SecureProtocols pentru a opri această eroare de canal securizat -2147012739.

' 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 

Stephen Quan

Depanarea codurilor de eroare:

  1. -2147012739 este un HRESULT.
  2. În hexazecimal este 0x80072F7D.
  3. Uitați-vă la LOWORD: 0x2F7D.
  4. Convertiți-o înapoi în zecimal: 12157.
  5. Căutați codurile de eroare 12157.
  6. Află că se potrivește: ERROR_WINHTTP_SECURE_CHANNEL_ERROR

Un pic de căutare pe Google găsește http://msdn.microsoft.com/en-us/library/windows/desktop/aa383770(v=vs.85).aspx care afirmă:

ERROR_WINHTTP_SECURE_CHANNEL_ERROR

12157

Indică faptul că s-a produs o eroare legată de un canal securizat (echivalentă cu codurile de eroare care încep cu „SEC_E_” și „SEC_I_” enumerate în fișierul antet „winerror.h”).

Cu toate acestea, ați descoperit deja acest lucru, deoarece mesajul pe care l-ați primit a fost „Description: A apărut o eroare în suportul canalului securizat”. Așadar, acest lucru ne conduce înapoi de unde am plecat.

Cealaltă observație pe care o fac este că codul dvs. este o cerere WinHTTP non-asincronă (știu că trebuie să fie așa pentru a funcționa în cadrul ASP), dar, îngrijorarea este că, datorită frecvenței ridicate, mașina dvs. ar putea procesa mai multe cereri WinHTTP simultan. Am văzut că unele Windows limitează în mod deliberat numărul total de cereri WinHTTP concurente active prin blocarea cererilor întârziate. De exemplu, pe o mașină cu Windows 7, un proces nu poate efectua mai mult de 2 cereri concurente către același server la distanță. De exemplu, a treia, a patra… cereri vor fi blocate până la finalizarea primelor două.

O soluție este echilibrarea încărcăturii solicitărilor primite pe mai mult de un grup de aplicații sau pe mai multe servere.

Tom Fahey

Am avut o variantă a acestei probleme și ne-a costat ceva timp să o rezolvăm.
Iată care este situația: Un server Linux mai vechi care găzduiește o aplicație scrisă în PHP și care furnizează date prin apeluri de servicii web. Serverul folosește HTTPS. Apelurile de la diverși clienți se fac cu cod care folosește biblioteca winHTTP 5.2. (Winhttp.dll)

Simptom: Clienții noștri primesc acum mesaje de eroare sporadice atunci când efectuează apeluri winHTTP repetate folosind o comandă „POST”. Mesajele sunt fie „Tampoanele tampon furnizate unei funcții au fost prea mici.”, fie „A apărut o eroare în suportul canalului securizat”. După multe căutări, am descoperit că serverul clientului înregistra ‘Schannel Event ID 36887 cod de alertă 20’ în Event Viewer, care corespundea cu mesajul de eroare vizibil.

Soluție: Nu este nevoie de o soluție: Am descoperit că vechiul nostru server Linux nu putea suporta TLS 1.2. (CentOS 5.11) Am aflat, de asemenea, că mai mulți dintre clienții noștri au aplicat recent (vara anului 2016) o actualizare la serverele lor Microsoft. (Server 2008, server 2012) Corecția a fost de a forța serverele lor să utilizeze TLS 1.1 pentru apelurile de servicii web. Partea care mi se pare destul de ciudată este că setările din Internet Explorer pentru modificarea TLS nu au avut niciun efect asupra problemei. Cu toate acestea, prin modificarea unei setări din Politici de grup am reușit să rezolvăm problema. Consilierul nostru tehnic în această privință a subliniat faptul că modificarea este într-adevăr obscură, dar că un furnizor terț a oferit o soluție rapidă. Instrumentul respectiv se numește IIS Crypto de la Nartac. https://www.nartac.com/Products/IISCrypto/Download Instrumentul vă permite să selectați în mod specific Protocoale. Acum primim un nou server pentru a găzdui aplicațiile noastre (CentOS 6) și atunci ar trebui să putem utiliza protocolul TLS 1.2!

coderpro.net

Am întâlnit și eu această eroare în urmă cu câteva luni. Cel mai adesea, această problemă este cauzată de un certificat SSL invalid. Având în vedere că la momentul postării tocmai migraseți pe un nou server, probabil că trebuie doar să reinstalați certificatul SSL.

Îmi dau seama că această întrebare este veche, dar sper că altcineva poate beneficia de răspunsul meu.