Une erreur s'est produite dans la requête HTTP HTTP Classic ASP De secure channel support.

j'ai un site Web ASP classique tournant sur une fenêtre Windows Server 2012. Une page envoie une requête HTTP à une autre application via https en utilisant le code suivant:

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

ce code fonctionne très bien presque tout le temps (des milliers de requêtes par jour), mais sporadiquement il échouera avec un message comme celui-ci:

numéro: -2147012739

Description: Une erreur s'est produite dans le canal sécurisé support

Source: msxml6.dll

l'application a été récemment déplacée d'un ancien serveur Windows 2003 vers le serveur 2012, et ce problème n'a jamais semblé être un problème sur l'ancien serveur. En outre, alors que cette erreur se produit sur le site web, Je pourrais exécuter le même code exact dans un VBScript et il fonctionne très bien. Le fait de réinitialiser le pool d'applications semble faire en sorte que le site soit à nouveau en mesure de faire les requêtes HTTP sécurisées (bien qu'il se corrige souvent lui-même avant que je puisse me rendre sur le serveur).

28
demandé sur bluish 2014-01-25 23:10:36

7 réponses

j'ai eu exactement le même problème après avoir migré de 2003 à 2008 R2 et j'ai trouvé la solution. Modifier:

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

à:

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

et que le problème va disparaître.

j'ai essayé de trouver les avantages et les inconvénients des deux objets, mais je n'ai pas encore trouvé de raison pour ne pas utiliser XMLHTTP.

16
répondu user3087157 2014-10-29 19:11:48

j'ai eu le même problème et essayé beaucoup de solutions offertes sous une variété de postes mais finalement eu aucun succès, jusqu'à présent. Je vais détailler la solution qui a fonctionné pour moi avec référence au problème comme dans mon cas C'était PayPal. Je n'ai pas ouvert un nouveau poste car cela pourrait ne pas être juste un problème paypal à l'avenir.

La solution est une combinaison d'un certain nombre de stackoverflow posté des solutions à des problèmes similaires, mais cela semblait plus à ajouter.

le problème

essayer de tester PayPal IPN sur Windows Server 2008 en utilisant classic ASP en utilisant le Sandbox de PayPal retourne l'erreur "une erreur s'est produite dans le support de secure channel".

Pourquoi c'est un problème

PayPal exige que toutes les communications avec leurs systèmes soient aussi sécurisées que possible. Vous aurez besoin d'une connexion TLS 1.2. Windows Server 2008 n'est pas TLS 1.2 par défaut.

PayPal a jeté une certaine confusion dans le mélange en disant que vous avez besoin d'un Verisign G5 certificate, ce que vous faites pour la racine du serveur mais pas pour le domaine sur lequel vous exécutez votre code. Je n'ai pas non plus installé de certificats PayPal car je n'utilise pas L'API. Je ne crois pas non plus que vous ayez besoin de vos comms depuis un site HTTPS - bien que mon domaine soit sécurisé grâce à un standard GoDaddy EV cert bien que j'ai fait un test sur un site non HTTPS après et cela a fonctionné aussi.

ma solution

  1. Vérifiez D'abord le type de sécurité que votre serveur utilise via SSL Labs. Il doit être TLS1.2 ou supérieur et pas d'autres TLS ou SSL. Il doit aussi avoir un cryptage SHA256. Vous pouvez avoir besoin de patcher le serveur: https://support.microsoft.com/en-us/kb/3106991.

  2. utilisez IISCrypto pour définir les bons TLS et chiffreurs. J'ai utilisé les changements de registre offerts ailleurs sur stackoverflow, mais cela n'a pas fonctionné et a complètement foiré mon serveur pour tout en utilisant HTTPS posts, pas seulement mon site de développement! IISCrypto gère aussi les chiffreurs.

  3. assurez-vous que votre dossier de candidature est v4.5, ce qui en soi n'est pas clair parce que IIS pourrait seulement offrir v4.0 en option. Cependant, il s'agit probablement en fait de v4.5. Vous pouvez le vérifier via https://msdn.microsoft.com/en-us/library/hh925568 (v=V110).aspx.

  4. Dans votre code, vous devez utiliser Server.CreateObject ("MSXML2.XMLHTTP.6.0"), pas Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0") comme mentionné surtout.

maintenant, je n'ai aucune idée pourquoi le non-serveur XMLHTTP fonctionne comme cela semble contraire à la documentation derrière lui. Maintenant, après 10 jours de stress, de panique et de frustration, je m'en fous! J'espère que cela est utile pour les autres.

trouver la solution a été un cauchemar donc je vais ajouter quelques phrases ci-dessous pour aider les autres si la recherche:

PayPal IPN échoué avec l'erreur de serveur

erreurs PayPal SSL Windows 2008

une erreur s'est produite dans le support de la voie de communication protégée

erreurs ASP Classic PayPal Sandbox SSL

7
répondu Steve Neale 2018-03-26 14:07:59

Codes d'erreur de dépannage:

  1. -2147012739 est un résultat.
  2. En hexadécimal c'est 0x80072F7D.
  3. voir la LOWORD: 0x2F7D.
  4. Convertissez ce retour en décimal: 12157.
  5. recherche 12157 codes d'erreur.
  6. trouver qu'il correspond: ERROR_WINHTTP_SECURE_CHANNEL_ERROR

un peu de Google-fu trouve http://msdn.microsoft.com/en-us/library/windows/desktop/aa383770 (v=vs 85).aspx qui stipule:

ERROR_WINHTTP_SECURE_CHANNEL_ERROR

12157

indique qu'une erreur s'est produite relativement à une voie de communication protégée (l'équivalent des codes d'erreur commençant par "SEC_E_E_" et "SEC_I_" inscrits dans le "winerror.h" fichier d'en-tête).

cependant, vous l'avez déjà découvert puisque le message que vous avez reçu était "Description: Une erreur s'est produite dans le support de la voie de communication protégée". Ça nous ramène là où on a commencé.

Les autres l'observation que je fais est que votre code est une requête WinHTTP non asynchrone (je sais qu'il doit être pour fonctionner à L'intérieur D'ASP), mais, le problème est, en raison de la haute fréquence, votre machine pourrait traiter plus d'une requête WinHTTP simultanément. J'ai vu que certaines fenêtres ralentissent délibérément le nombre total de requêtes WinHTTP simultanées actives en bloquant les requêtes tardives. Par exemple, sur une machine Windows 7, un processus ne peut pas faire plus de 2 requêtes simultanées vers le même serveur distant. c'est à dire Le 3, le 4... les demandes seront bloqués jusqu'à ce que le premier deux.

une solution consiste à équilibrer les requêtes entrantes sur plus d'un pool d'applications ou sur plusieurs serveurs.

2
répondu Stephen Quan 2014-04-22 13:50:58

tout est valide cependant le bit manquant "critique" pour TLS1.2 Prise en charge sur Windows 7 avec IIS7.5 and classic asp is setting this in the registry: -

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

j'espère que ça vous évitera une journée de farce, de redémarrage et de grattage de la tête! :)

cet extrait de code est utile pour les tests. 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 
%>
1
répondu Gruff 2016-09-12 12:45:53

nous avons eu une variation sur ces questions et cela nous a vraiment coûté du temps pour le comprendre.

Voici la situation: un vieux serveur Linux hébergeant une application écrite en PHP et fournissant des données via des appels webservice. Le serveur utilise le protocole HTTPS. Les appels de divers clients sont effectués avec le code en utilisant la bibliothèque winHTTP 5.2. (Winhttp.dll)

symptôme: nos clients reçoivent maintenant des messages d'erreur sporadiques lorsqu'ils font des appels winHTTP répétés en utilisant une commande "POST". Le les messages sont soit " les tampons fournis à une fonction étaient trop petits."ou" Une erreur s'est produite dans le canal sécurisé support". Après de nombreuses recherches, nous avons découvert que le serveur du client était en train de se connecter ‘Schannel Event ID 36887 alert code 20’ dans le visualiseur D'événement qui correspondait au message d'erreur visible.

Solution: nous avons découvert que notre ancien serveur Linux ne pouvait pas prendre en charge TLS 1.2. (CentOS 5.11) nous avons également appris que plusieurs de nos clients avaient récemment (été 2016) appliqué une mise à jour à leurs serveurs Microsoft. (Server 2008, server 2012) le correctif était de forcer leurs serveurs à utiliser TLS 1.1 Pour les appels webservice. La partie qui est plutôt étrange pour moi est que les paramètres dans Internet Explorer pour changer le TLS n'ont pas eu d'effet sur le problème. Toutefois, en modifiant le cadre des politiques de groupe, nous avons pu résoudre le problème. Notre conseiller technique sur cette question, a souligné que le changement est vraiment obscure, mais qu'un fournisseur tiers a fourni une solution rapide. Cet outil s'appelle IIS Crypto de Nartac. https://www.nartac.com/Products/IISCrypto/Download L'outil vous permet de sélectionner des protocoles spécifiques. Nous avons maintenant un nouveau serveur pour héberger nos applications (CentOS 6) et nous devrions pouvoir utiliser le protocole TLS 1.2!

1
répondu Tom Fahey 2016-10-05 21:33:06

dans un script ASP classique de Windows Server 2016, récupérant une URL HTTPS de Windows Server 2012 R2, j'ai récemment dû supprimer SSL 2.0 de SecureProtocols afin d'arrêter cette erreur de secure channel -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 
1
répondu stevek_mcc 2018-09-05 20:54:10

j'ai moi-même rencontré cette erreur il y a quelques mois. Le plus souvent, ce problème est causé par un certificat SSL invalide. Considérant qu'au moment du post vous veniez de migrer vers un nouveau serveur, vous avez probablement juste besoin de réinstaller le certificat SSL.

je me rends compte que cette question Est ancienne, mais j'espère que quelqu'un d'autre pourra bénéficier de ma réponse.

0
répondu coderpros 2014-09-30 04:52:35