Une erreur s'est produite dans la prise en charge du canal sécurisé - Classique ASP Requête HTTP
J'ai un site Web classique ASP fonctionnant sur une boîte Windows Server 2012. Une page fait une demande HTTP à une autre application via https en utilisant du code comme celui-ci:
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 demandes par jour), mais il échouera sporadiquement avec un message comme celui-ci:
Numéro: -2147012739
Description: une erreur s'est produite dans la prise en charge du canal sécurisé
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. De plus, alors que cette erreur se produit sur le site Web, je pourrais exécuter exactement le même code dans un VBScript et cela fonctionne très bien. La réinitialisation du pool d'applications semble permettre au site de pouvoir à nouveau effectuer les requêtes HTTP sécurisées (bien qu'il se répare souvent avant que je puisse accéder au serveur).
J'ai eu exactement le même problème après avoir migré de 2003 à 2008 R2 et trouvé la solution. Changement:
Set objhttp = Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0")
à:
Set objhttp = Server.CreateObject ("MSXML2.XMLHTTP.6.0")
et votre problème disparaîtra.
J'ai essayé de trouver les avantages et les inconvénients des deux objets, mais je n'ai pas encore trouvé de raison de ne pas utiliser XMLHTTP.
J'ai eu le même problème et j'ai essayé de nombreuses solutions proposées sous divers postes, mais finalement, je n'ai pas réussi jusqu'à présent. Je vais détailler la solution qui a fonctionné pour moi en référence au problème car dans mon cas c'était Paypal. Je n'ai pas ouvert de nouveau message car cela pourrait ne plus être un problème Paypal à l'avenir.
La solution est une combinaison d'un certain nombre de solutions postées par stackoverflow pour des problèmes similaires, mais cela semblait la meilleure à ajouter.
Le problème
Essayer de tester Paypal IPN sur Windows Server 2008 en utilisant classique ASP en utilisant le sandbox Paypal renvoie l'erreur "Une erreur s'est produite dans le support du canal sécurisé").
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 qui est TLS 1.2. Windows Server 2008 n'est pas TLS 1.2 par défaut.
Paypal a semé la confusion dans le mélange en disant que vous avez besoin d'un certificat Verisign G5, ce que vous faites pour la racine du serveur mais pas 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 pense pas non plus que vous ayez besoin de vos communications à partir d'un site HTTPS - bien que mon domaine soit sécurisé à l'aide d'un certificat GoDaddy EV standard, bien que j'aie fait un test sur un site non HTTPS par la suite et que cela ait aussi fonctionné.
Ma solution
Vérifiez d'abord quel type de sécurité votre serveur utilise via SSL Labs . Il doit être TLS1.2 ou supérieur et aucun autre TLS ou SSL. Il doit également avoir un cryptage SHA256. Vous devrez peut-être patcher le serveur: https://support.Microsoft.com/en-us/kb/3106991 .
Utilisez IISCrypto pour définir le TLS et les chiffres appropriés . J'ai utilisé les modifications de registre proposées ailleurs sur stackoverflow mais cela n'a pas fonctionné et a complètement foiré mon serveur pour tout en utilisant les publications HTTPS, pas seulement mon site de développement! IISCrypto gère également les chiffres.
Assurez-vous que votre pool d'applications est v4.5 , ce qui en soi n'est pas clair car IIS pourrait ne proposer que v4.0 en option. Cependant, il s'agit probablement de la version 4.5. Vous pouvez le vérifier via https://msdn.Microsoft.com/en-us/library/hh925568 (v = vs.110) .aspx =.
Dans votre code, vous devez utiliser
Server.CreateObject ("MSXML2.XMLHTTP.6.0"), pasServer.CreateObject ("MSXML2.ServerXMLHTTP.6.0")comme mentionné ci-dessus.
Maintenant, je ne sais pas pourquoi XMLHTTP non serveur fonctionne car cela semble contraire à la documentation derrière. En ce moment, après 10 jours de stress, de panique et de frustration, je m'en fiche! J'espère que cela sera utile pour les autres.
Trouver la solution était un cauchemar, je vais donc ajouter quelques phrases ci-dessous pour aider les autres en cas de recherche:
Échec de l'IPN Paypal avec une erreur de serveur
Erreurs Paypal SSL Windows 2008
Une erreur s'est produite dans la prise en charge du canal sécurisé
classique ASP Erreurs SSL Paypal Sandbox
Je tiens à remercier publiquement Rackspace et GoDaddy pour leur aide à cet égard. Je voudrais déclarer publiquement que j'ai trouvé que Paypal a le pire support technique de tous les temps et ne s'en soucie pas, pointant constamment ses propres documents, s'il répond jamais. Ils disent qu'ils envoient des courriels à ce sujet depuis septembre 2014, mais je n'en ai jamais reçu. Ces nouvelles exigences sont actives sur le bac à sable Paypal, mais elles seront mises en service en septembre 2016. Je ne les ai rencontrées que lors du développement d'une nouvelle solution, donc j'avais besoin du bac à sable - si vous exécutez en direct, vous ne saurez pas le problème avant qu'il ne frappe et tu es mort dans l'eau. Testez votre système de paiement complet sur le sandbox Paypal dès que possible est mon conseil !!
Aucune des réponses ci-dessus ne s'applique à ma situation. Ensuite, j'ai sauté sur le lien ici:
Cette mise à jour prend en charge Transport Layer Security (TLS) 1.1 et TLS 1.2 dans Windows Server 2012, Windows 7 Service Pack 1 (SP1) et Windows Server 2008 R2 SP1.
Les applications et services écrits à l'aide de WinHTTP pour les connexions SSL (Secure Sockets Layer) qui utilisent l'indicateur WINHTTP_OPTION_SECURE_PROTOCOLS ne peuvent pas utiliser les protocoles TLS 1.1 ou TLS 1.2. En effet, la définition de cet indicateur n'inclut pas ces applications et services.
Cette mise à jour ajoute la prise en charge de l'entrée de registre DefaultSecureProtocols qui permet à l'administrateur système de spécifier les protocoles SSL à utiliser lorsque l'indicateur WINHTTP_OPTION_SECURE_PROTOCOLS est utilisé.
Cela peut permettre à certaines applications qui ont été construites d'utiliser l'indicateur par défaut WinHTTP pour pouvoir exploiter les nouveaux protocoles TLS 1.2 ou TLS 1.1 en mode natif sans avoir besoin de mises à jour de l'application.
C'est le cas pour certaines applications Microsoft Office lorsqu'elles ouvrent des documents à partir d'une bibliothèque SharePoint ou d'un dossier Web, des tunnels IP-HTTPS pour la connectivité DirectAccess et d'autres applications en utilisant des technologies telles que WebClient en utilisant WebDav, WinRM et autres.
Cette mise à jour ne changera pas le comportement des applications qui définissent manuellement les protocoles sécurisés au lieu de passer l'indicateur par défaut.
Client service sur Windows 2008 R2 le serveur sortant vers le serveur via TLS a renvoyé l'erreur en question. Je pensais que cela pourrait être la compatibilité de la suite de chiffrement. Wireshark trace la version indiquée dans Client Hello la demande était TLS 1.0 mais le serveur nécessite TLS 1.2. Les suites de chiffrement envoyées au serveur sortant par le service client étaient correctes. Le problème est que le service client ou l'application sur le serveur Windows par défaut utilise le système par défaut, qui n'est pas TLS 1.2.
La solution consiste à ajouter une sous-clé de registre nommée DefaultSecureProtocols avec une valeur correspondant à la ou aux versions TLS à prendre en charge. Ajoutez ladite sous-clé de registre, de type DWORD, aux emplacements suivants:
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
- HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
Pour le correctif d'Internet Explorer, vous pouvez ajouter une sous-clé de registre similaire intitulée SecureProtocols, également de type DWORD, aux emplacements suivants:
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
- Paramètres HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\
Vous trouverez ci-dessous le tableau des valeurs des deux sous-clés:
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
Par exemple:
L'administrateur souhaite remplacer les valeurs par défaut de WINHTTP_OPTION_SECURE_PROTOCOLS pour spécifier TLS 1.1 et TLS 1.2.
Prenez la valeur pour TLS 1.1 (0x00000200) et la valeur pour TLS 1.2 (0x00000800) puis ajoutez-les ensemble dans la calculatrice (en mode programmeur), la valeur de registre résultante serait 0x00000A00.
J'ai appliqué 0x00000A00 comme valeur pour les deux sous-clés et cela a réussi à résoudre le problème.
Il existe également Easy Fix (le lien est ici: https://aka.ms/easyfix51044 ) disponible auprès de Microsoft, si vous ne souhaitez pas saisir manuellement les sous-clés et les valeurs du registre.
Dépannage des codes d'erreur:
- -2147012739 est un HRESULT.
- En hexadécimal, c'est 0x80072F7D.
- Regardez le LOWORD: 0x2F7D.
- Convertissez cela en décimal: 12157.
- Rechercher les codes d'erreur 12157.
- Trouvez 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 dit:
ERROR_WINHTTP_SECURE_CHANNEL_ERROR
12157
Indique qu'une erreur s'est produite concernant un canal sécurisé (équivalent aux codes d'erreur commençant par "SEC_E_" et "SEC_I_" répertoriés dans le fichier d'en-tête "winerror.h").
Cependant, vous l'avez déjà découvert car le message que vous avez reçu était "Description: une erreur s'est produite dans la prise en charge du canal sécurisé". Cela nous ramène donc là où nous avons commencé.
L'autre observation que je fais est que votre code est une demande WinHTTP non asynchrone (je sais qu'elle doit fonctionner à l'intérieur d'ASP), mais, le problème est, en raison de la fréquence élevée, que votre machine pourrait traiter plus d'un WinHTTP demander simultanément. J'ai vu certains Windows limiter délibérément le nombre total de demandes WinHTTP simultanées actives en bloquant les demandes tardives. Par exemple, sur une machine Windows 7, un processus ne peut pas effectuer plus de 2 requêtes simultanées vers le même serveur distant. c'est-à-dire que les 3ème, 4ème ... demandes seront bloquées jusqu'à ce que les deux premières soient terminées.
Une solution consiste à équilibrer la charge des demandes entrantes sur plusieurs pools d'applications ou sur plusieurs serveurs.
Nous avions une variation sur ces questions et cela nous a vraiment coûté du temps pour le comprendre.
Voici la situation: Un ancien serveur Linux hébergeant une application écrite en PHP et fournit des données via des appels de service Web. Le serveur utilise HTTPS. Les appels de divers clients sont effectués avec du code à l'aide de la bibliothèque winHTTP 5.2. (Winhttp.dll)
Symptôme: nos clients reçoivent désormais des messages d’erreurs sporadiques lors des appels répétés de winHTTP à l’aide d’une commande ‘POST’. Les messages sont "Les tampons fournis à une fonction étaient trop petits" ou "Une erreur s'est produite dans la prise en charge du canal sécurisé". Après de nombreuses recherches, nous avons découvert que le serveur du client enregistrait "Schannel Event ID 36887 alert code 20" dans l'Observateur d'événements 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 consistait à forcer leurs serveurs à utiliser TLS 1.1 pour les appels de service Web. La partie qui m'est assez étrange est que les paramètres d'Internet Explorer pour changer le TLS n'ont eu aucun effet sur le problème. Cependant, en modifiant un paramètre dans les stratégies de groupe, nous avons pu résoudre le problème. Notre conseiller technique à ce sujet a souligné que le changement est vraiment obscur, mais qu'un fournisseur tiers a fourni une solution rapide. Cet outil est appelé IIS Crypto de Nartac. https://www.nartac.com/Products/IISCrypto/Download L'outil vous permet de sélectionner spécifiquement des protocoles. Nous sommes obtenir maintenant un nouveau serveur pour héberger nos applications (CentOS 6) et devrait alors pouvoir utiliser le protocole TLS 1.2!
Tout est valide, mais le bit manquant "critique" pour la prise en charge de TLS1.2 sur Windows 7 avec IIS7.5 et asp classique le définit dans le registre: -
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000800
J'espère que cela vous évite une journée de faffing, de redémarrage et de grattage de 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
%>
Dans un Windows Server 2016 Classic ASP, récupérant une URL HTTPS à partir de Windows Server 2012 R2, j'ai récemment dû supprimer SSL 2.0 de SecureProtocols afin d'arrêter cette erreur de canal sécurisé -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
J'ai moi-même rencontré cette erreur il y a quelques mois. Le plus souvent, ce problème est dû à un certificat SSL non valide. Étant donné qu'au moment de la publication, vous veniez de migrer vers un nouveau serveur, il vous suffit probablement 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.