iis - solicitud - no se puede establecer un canal seguro para ssl tls con la autoridad

Ocurrió un error en la compatibilidad del canal seguro: solicitud clásica ASP HTTP (6)

Tengo un sitio web ASP clásico ejecutándose en un cuadro de Windows Server 2012. Una página realiza una solicitud HTTP a otra aplicación a través de https utilizando un código como este:

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

Este código funciona bien casi todo el tiempo (miles de solicitudes por día), pero esporádicamente fallará con un mensaje como este:

Número: -2147012739
Descripción: se produjo un error en el soporte de canal seguro
Fuente: msxml6.dll

La aplicación se movió recientemente de un antiguo servidor de Windows 2003 al servidor de 2012, y este problema nunca pareció ser un problema en el servidor anterior. Además, aunque este error está ocurriendo en el sitio web, podría ejecutar exactamente el mismo código en un VBScript y funciona bien. Restablecer el grupo de aplicaciones parece hacer que el sitio vuelva a realizar las solicitudes HTTP seguras (aunque a menudo se soluciona antes de que pueda acceder al servidor).

He tenido el mismo problema e intenté muchas soluciones ofrecidas en una variedad de publicaciones, pero finalmente no tuve éxito hasta ahora. Detallaré la solución que funcionó para mí con referencia al problema, ya que en mi caso era PayPal. No abrí una publicación nueva, ya que podría no ser solo un problema de PayPal en el futuro.

La solución es una combinación de varias soluciones publicadas de para problemas similares, pero esta parecía ser la mejor para agregar.

El problema

Intentar probar PayPal IPN en Windows Server 2008 utilizando ASP clásico utilizando PayPal Sandbox devuelve el error "Ocurrió un error en el soporte de canal seguro".

Por qué es un problema

PayPal exige que todas las comunicaciones con sus sistemas sean lo más seguras posible. Necesitará una conexión que sea TLS 1.2. Windows Server 2008 no es TLS 1.2 de manera predeterminada.

PayPal arrojó algo de confusión en la mezcla al decir que necesita un certificado Verisign G5, que hace para la raíz del servidor pero no para el dominio en el que está ejecutando el código. Tampoco instalé ningún certificado de PayPal porque no uso la API. Tampoco creo que necesite sus comunicaciones de un sitio HTTPS, aunque mi dominio está protegido con un certificado GoDaddy EV estándar, aunque hice una prueba en un sitio que no era HTTPS y eso también funcionó.

Mi solución

Primero compruebe qué tipo de seguridad está utilizando su servidor a través de SSL Labs . Debe ser TLS1.2 o superior y ningún otro TLS o SSL. También debe tener un cifrado SHA256. Es posible que deba aplicar un parche al servidor: https://support.microsoft.com/en-us/kb/3106991 .
Use IISCrypto para establecer los TLS y cifrados correctos . Utilicé los cambios de registro ofrecidos en otros lugares en , pero esto no funcionó y en realidad arruiné totalmente mi servidor para todo usando publicaciones HTTPS, ¡no solo mi sitio de desarrollo! IISCrypto también maneja las cifras.
Asegúrese de que su grupo de aplicaciones sea v4.5 , lo que en sí mismo no está claro porque IIS solo podría ofrecer v4.0 como una opción. Sin embargo, esto es probablemente en realidad v4.5. Puede verificar esto a través de https://msdn.microsoft.com/en-us/library/hh925568(v=vs.110).aspx .
Dentro de su código, necesita usar Server.CreateObject ("MSXML2.XMLHTTP.6.0") , no Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0") como se mencionó anteriormente.

Ahora no tengo idea de por qué el XMLHTTP que no es servidor funciona como parece contrario a la documentación detrás de él. En este momento, después de 10 días de estrés, pánico y frustración, ¡no me importa! Espero que esto sea útil para otros.

Encontrar la solución fue una pesadilla, así que agregaré algunas frases a continuación para ayudar a los demás si buscas:

Error de IPN de PayPal con error del servidor
Errores de PayPal SSL Windows 2008
Se produjo un error en el soporte de canal seguro
clásico ASP errores SSL de Sandbox de PayPal

Me gustaría agradecer públicamente a Rackspace y GoDaddy por su ayuda con esto. Me gustaría declarar públicamente que encontré que PayPal tiene el peor soporte técnico que haya existido nunca y no me importa, constantemente señalando sus propios documentos, si alguna vez responden. Dicen que han estado enviando correos electrónicos sobre esto desde septiembre de 2014, pero nunca recibí uno. Estos nuevos requisitos están activos en el banco de pruebas de PayPal, pero se lanzarán en septiembre de 2016. Solo lo encontré como el desarrollo de una nueva solución, así que necesitaba el sandbox: si está ejecutando en vivo, no sabrá el problema hasta que llegue y luego estás muerto en el agua. Pon a prueba tu sistema de pago completo en la caja de arena de PayPal lo antes posible. ¡Es mi consejo!

He tenido exactamente el mismo problema después de migrar de 2003 a 2008 R2 y encontré la solución. Cambio:

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

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

y tu problema desaparecerá

Traté de encontrar los pros y los contras de ambos objetos, pero aún no he encontrado una razón para no usar XMLHTTP.

Me encontré con este error hace unos meses. La mayoría de las veces, este problema es causado por un certificado SSL no válido. Teniendo en cuenta que, en el momento de la publicación, acababa de migrar a un nuevo servidor, probablemente solo necesite volver a instalar el certificado SSL.

Me doy cuenta de que esta pregunta es antigua, pero espero que alguien más pueda beneficiarse de mi respuesta.

Solucionar problemas de códigos de error:

-2147012739 es un HRESULT.
En hexadecimal, es 0x80072F7D.
Mire el LOWORD: 0x2F7D.
Convierta eso de vuelta a decimal: 12157.
Buscar códigos de error 12157.
Encuentra que coincide con: ERROR_WINHTTP_SECURE_CHANNEL_ERROR

Un poco de Google-fu encuentra http://msdn.microsoft.com/en-us/library/windows/desktop/aa383770(v=vs.85).aspx que dice:

ERROR_WINHTTP_SECURE_CHANNEL_ERROR

12157

Indica que se ha producido un error relacionado con un canal seguro (equivalente a los códigos de error que comienzan con "SEC_E_" y "SEC_I_" enumerados en el archivo de encabezado "winerror.h").

Sin embargo, ya descubrió esto ya que el mensaje que recibió fue "Descripción: se produjo un error en la compatibilidad con el canal seguro". Entonces, esto nos lleva de regreso al lugar donde comenzamos.

La otra observación que hago es que su código es una solicitud WinHTTP no asíncrona (sé que tiene que ser para funcionar dentro de ASP), pero la preocupación es que, debido a la alta frecuencia, su máquina podría procesar más de un WinHTTP solicitar concurrentemente He visto que algunos Windows aceleran deliberadamente el número total de solicitudes simultáneas activas de WinHTTP al bloquear las solicitudes tardías. Por ejemplo, en una máquina con Windows 7, un proceso no puede realizar más de 2 solicitudes concurrentes al mismo servidor remoto. es decir, las solicitudes 3ª, 4ª ... se bloquearán hasta que se completen las dos primeras.

Una solución es equilibrar la carga de solicitudes entrantes en más de un grupo de aplicaciones o en más servidores.

Todo es válido, sin embargo, el bit "crítico" que falta para la compatibilidad con TLS1.2 en Windows 7 con IIS7.5 y el ASP clásico está estableciendo esto en el registro: -

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

¡Espero que eso te salve un día de desilusión, reinicio y rasguños en la cabeza! :)

Este fragmento de código es útil para probar. 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 %>

Tuvimos una variación en estos temas y realmente nos costó algo de tiempo resolverlo.
Aquí está la situación: un servidor Linux anterior que aloja una aplicación escrita en PHP y proporciona datos a través de llamadas a servicios web. El servidor está usando HTTPS. Las llamadas de varios clientes se realizan con código utilizando la biblioteca winHTTP 5.2. (Winhttp.dll)

Síntoma: nuestros clientes ahora reciben mensajes de error esporádicos al realizar llamadas winHTTP repetidas usando un comando ''POST''. Los mensajes son ''Los búferes suministrados a una función eran pequeños''. o ''Se produjo un error en el soporte de canal seguro''. Después de mucha búsqueda descubrimos que el servidor del cliente estaba registrando ''Schannel Event ID 36887 código de alerta 20'' en el Visor de eventos que correspondía con el mensaje de error visible.

Solución: Descubrimos que nuestro antiguo servidor Linux no podía soportar TLS 1.2. (CentOS 5.11) También nos enteramos de que varios de nuestros clientes recientemente (verano de 2016) aplicaron una actualización a sus servidores de Microsoft. (Servidor 2008, servidor 2012) La solución fue forzar a sus servidores a usar TLS 1.1 para las llamadas al servicio web. La parte que me resulta bastante extraña es que la configuración en Internet Explorer para cambiar el TLS no tuvo ningún efecto sobre el problema. Sin embargo, al cambiar una configuración en Políticas de grupo, pudimos resolver el problema. Nuestro asesor técnico sobre este asunto señaló que el cambio es realmente oscuro, pero que un proveedor externo ha proporcionado una solución rápida. Esa herramienta se llama IIS Crypto de Nartac. https://www.nartac.com/Products/IISCrypto/Download La herramienta le permite seleccionar Protocolos específicamente. ¡Ahora estamos obteniendo un nuevo servidor para alojar nuestras aplicaciones (CentOS 6) y luego deberíamos poder usar el protocolo TLS 1.2!