c# - relación - webexception: anulada la solicitud: no se puede crear un canal seguro ssl/tls

La solicitud fue abortada: no se pudo crear el canal seguro SSL/TLS (30)

No podemos conectarnos a un servidor HTTPS usando WebRequest debido a este mensaje de error:

The request was aborted: Could not create SSL/TLS secure channel.

Sabemos que el servidor no tiene un certificado HTTPS válido con la ruta utilizada, pero para evitar este problema, usamos el siguiente código que hemos tomado de otra publicación de StackOverflow:

private void Somewhere() { ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(AlwaysGoodCertificate); } private static bool AlwaysGoodCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors) { return true; }

El problema es que el servidor nunca valida el certificado y falla con el error anterior. ¿Alguien tiene alguna idea de lo que debo hacer?

Debo mencionar que un colega y yo realizamos pruebas hace unas semanas y estaba funcionando bien con algo similar a lo que escribí anteriormente. La única "gran diferencia" que hemos encontrado es que estoy usando Windows 7 y él estaba usando Windows XP. ¿Eso cambia algo?

System.Net.WebException: se canceló la solicitud: no se pudo crear el canal seguro SSL / TLS.

En nuestro caso, utilizamos un proveedor de software, por lo que no tuvimos acceso para modificar el código .NET. Aparentemente .NET 4 no usará TLS v 1.2 a menos que haya un cambio.

La solución para nosotros fue agregar la clave SchUseStrongCrypto al registro. Puede copiar / pegar el siguiente código en un archivo de texto con la extensión .reg y ejecutarlo. Sirvió como nuestro "parche" al problema.

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Microsoft/.NETFramework/v4.0.30319] "SchUseStrongCrypto"=dword:00000001 [HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/.NETFramework/v4.0.30319] "SchUseStrongCrypto"=dword:00000001

Éste está trabajando para mí en webclient MVC

public string DownloadSite(string RefinedLink) { try { Uri address = new Uri(RefinedLink); ServicePointManager.ServerCertificateValidationCallback = delegate { return true; }; ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3; System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12; using (WebClient webClient = new WebClient()) { var stream = webClient.OpenRead(address); using (StreamReader sr = new StreamReader(stream)) { var page = sr.ReadToEnd(); return page; } } } catch (Exception e) { log.Error("DownloadSite - error Lin = " + RefinedLink, e); return null; } }

Además de las respuestas anteriores, asegúrese de haber importado el certificado CER y NO el archivo PFX en su tienda local de máquinas. Un error común cuando tienes ambos archivos.

Algo que la respuesta original no tenía. Agregué un poco más de código para hacerlo a prueba de balas.

ServicePointManager.Expect100Continue = true; ServicePointManager.DefaultConnectionLimit = 9999; ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;

Asegúrese de que la configuración de ServicePointManager se realice antes de que se realice HttpWebRequest; de lo contrario, no funcionará.

Trabajos:

ServicePointManager.Expect100Continue = true; ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3; HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

Falla

HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/") ServicePointManager.Expect100Continue = true; ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;

Como puede ver, hay muchas razones por las que esto puede suceder. Pensé que añadiría la causa que encontré ...

Si establece el valor de WebRequest.Timeout en 0 , esta es la excepción que se produce. A continuación se muestra el código que tenía ... (Excepto en lugar de un 0 codificado para el valor de tiempo de espera, tuve un parámetro que se estableció inadvertidamente en 0 ).

WebRequest webRequest = WebRequest.Create(@"https://myservice/path"); webRequest.ContentType = "text/html"; webRequest.Method = "POST"; string body = "..."; byte[] bytes = Encoding.ASCII.GetBytes(body); webRequest.ContentLength = bytes.Length; var os = webRequest.GetRequestStream(); os.Write(bytes, 0, bytes.Length); os.Close(); webRequest.Timeout = 0; //setting the timeout to 0 causes the request to fail WebResponse webResponse = webRequest.GetResponse(); //Exception thrown here ...

Después de muchas horas con este mismo problema, encontré que la cuenta ASP.NET en la que se estaba ejecutando el servicio del cliente no tenía acceso al certificado. Lo arreglé entrando en el grupo de aplicaciones IIS en el que se ejecuta la aplicación web, entrando en Configuración avanzada y cambiando la identidad a la cuenta LocalSystem desde NetworkService .

Una mejor solución es conseguir que el certificado funcione con la cuenta de NetworkService predeterminada, pero esto funciona para realizar pruebas funcionales rápidas.

El error es genérico y hay muchas razones por las que la negociación SSL / TLS puede fallar. El más común es un certificado de servidor caducado o no válido, y usted se encargó de eso al proporcionar su propio enlace de validación de certificado de servidor, pero no es necesariamente la única razón. El servidor puede requerir autenticación mutua, puede configurarse con una serie de cifrados que no son compatibles con su cliente, puede tener una desviación de tiempo demasiado grande para que el protocolo de enlace tenga éxito y muchas más razones.

La mejor solución es utilizar el conjunto de herramientas de solución de problemas de SChannel. SChannel es el proveedor de SSPI responsable de SSL y TLS y su cliente lo usará para el protocolo de enlace. Eche un vistazo a las herramientas y configuraciones de TLS / SSL .

También vea Cómo habilitar el registro de eventos de Schannel .

El predeterminado .NET ServicePointManager.SecurityProtocol usa SSLv3 y TLS. Si está accediendo a un servidor Apache, hay una variable de configuración llamada SSLProtocol que por defecto es TLSv1.2. Puede configurar el ServicePointManager.SecurityProtocol para que use el protocolo apropiado compatible con su servidor web o puede cambiar su configuración de Apache para permitir que todos los protocolos como este SSLProtocol .

El problema para mí era que estaba intentando implementar en IIS como un servicio web, instalé el certificado en el servidor, pero el usuario que ejecuta IIS no tenía los permisos correctos en el certificado.

¿Cómo otorgar a ASP.NET acceso a una clave privada en un certificado en el almacén de certificados?

El problema que tiene es que el usuario de aspNet no tiene acceso al certificado. Tienes que dar acceso usando el winhttpcertcfg.exe

Un ejemplo de cómo configurar esto es en: http://support.microsoft.com/kb/901183

Bajo el paso 2 en más información.

EDITAR: en las versiones más recientes de IIS, esta función está integrada en la herramienta de administración de certificados, y se puede acceder haciendo clic derecho en el certificado y utilizando la opción para administrar claves privadas. Más detalles aquí: https://serverfault.com/questions/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791#132791

En caso de que el cliente sea una máquina con Windows, una posible razón podría ser que el protocolo tls o ssl requerido por el servicio no esté activado.

Esto se puede establecer en:

Panel de control -> Red e Internet -> Opciones de Internet -> Avanzado

Desplácese a la configuración hasta "Seguridad" y elija entre

Utilizar SSL 2.0
Utilizar SSL 3.0
Utilice TLS 1.0
Utilice TLS 1.1
Utilizar TLS 1.2

En mi caso tuve este problema cuando un servicio de Windows intentó conectarse a un servicio web. Buscando en los eventos de Windows finalmente encontré un código de error.

Evento ID 36888 (Schannel) se plantea:

The following fatal alert was generated: 40. The internal error state is 808.

Finalmente se relacionó con un Hotfix de Windows. En mi caso: KB3172605 y KB3177186

La solución propuesta en el foro vmware fue agregar una entrada de registro en Windows. Después de agregar el siguiente registro todo funciona bien.

[HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet / Control / SecurityProviders / SCHANNEL / KeyExchangeAlgorithms / Diffie-Hellman]

"ClientMinKeyBitLength" = dword: 00000200

Aparentemente está relacionado con un valor faltante en el protocolo de enlace https en el lado del cliente.

Enumere su HotFix de Windows:

wmic qfe list

Hilo de la solución:

https://communities.vmware.com/message/2604912#2604912

Espero que sea de ayuda.

En mi caso, la cuenta de servicio que ejecuta la aplicación no tenía permiso para acceder a la clave privada. Una vez que di este permiso, el error desapareció.

mmc
certificados
Expandir a personal
seleccione cert
botón derecho del ratón
Todas las tareas
Administrar claves privadas
Añadir

Esta pregunta puede tener muchas respuestas, ya que se trata de un mensaje de error genérico. Nos encontramos con este problema en algunos de nuestros servidores, pero no en nuestras máquinas de desarrollo. Después de sacar la mayor parte de nuestro cabello, descubrimos que era un error de Microsoft.

https://support.microsoft.com/en-us/help/4458166/applications-that-rely-on-tls-1-2-strong-encryption-experience-connect

Básicamente, MS asume que desea un cifrado más débil, pero el sistema operativo está parcheado para permitir solo TLS 1.2, por lo que recibe el temido "La solicitud fue cancelada: no se pudo crear el canal seguro SSL / TLS".

Hay tres correcciones.

1) Actualice el sistema operativo con la actualización adecuada: http://www.catalog.update.microsoft.com/Search.aspx?q=kb4458166

2) Agregue una configuración a su archivo app.config / web.config.

3) Agregue una configuración de registro que ya se mencionó en otra respuesta.

Todo esto se menciona en el artículo de la base de conocimientos que publiqué.

Esto me estaba sucediendo en un solo sitio, y resulta que solo tenía el código RC4 disponible. En un esfuerzo previo para fortalecer el servidor, había deshabilitado el cifrado RC4, una vez que volví a habilitar esto, el problema se resolvió.

Finalmente encontré la respuesta (no he notado mi fuente pero fue de una búsqueda);

Mientras el código funciona en Windows XP, en Windows 7, debe agregar esto al principio:

// using System.Net; ServicePointManager.Expect100Continue = true; ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; // Use SecurityProtocolType.Ssl3 if needed for compatibility reasons

Y ahora, funciona perfectamente.

APÉNDICE

Como lo menciona Robin French; si tiene este problema al configurar PayPal, tenga en cuenta que no admitirán SSL3 a partir del 3 de diciembre de 2018. Deberá usar TLS. Aquí está la página de Paypal al respecto.

He luchado con este problema todo el día.

Cuando creé un nuevo proyecto con .NET 4.5 finalmente lo hice funcionar.

Pero si bajé de categoría a 4.0, volví a tener el mismo problema y fue irreversible para ese proyecto (incluso cuando intenté actualizar a 4.5 nuevamente).

Extraño ningún otro mensaje de error, pero "La solicitud fue abortada: no se pudo crear el canal seguro SSL / TLS". surgió por este error

La excepción "La solicitud fue cancelada: No se pudo crear el canal seguro SSL / TLS" puede ocurrir si el servidor devuelve una respuesta HTTP 401 no autorizada a la solicitud HTTP.

Puede determinar si esto sucede activando el registro de System.Net a nivel de rastreo para su aplicación cliente, como se describe en esta respuesta .

Una vez que la configuración de registro esté en su lugar, ejecute la aplicación y reproduzca el error, luego busque en la salida del registro una línea como esta:

System.Net Information: 0 : [9840] Connection#62912200 - Received status line: Version=1.1, StatusCode=401, StatusDescription=Unauthorized.

En mi situación, no pude establecer una cookie particular que el servidor esperaba, lo que provocó que el servidor respondiera a la solicitud con el error 401, que a su vez llevó a la excepción "No se pudo crear el canal seguro SSL / TLS".

La raíz de esta excepción en mi caso fue que en algún punto del código se llamaba a lo siguiente:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Esto es realmente malo. No solo le está ordenando a .NET que use un protocolo inseguro, sino que esto impacta cada nueva solicitud de WebClient (y similar) realizada posteriormente dentro de su dominio de aplicación. (Tenga en cuenta que las solicitudes web entrantes no se ven afectadas en su aplicación ASP.NET, pero las nuevas solicitudes de Clientes web, como hablar con un servicio web externo).

En mi caso, no fue realmente necesario, así que simplemente pude eliminar la declaración y todas mis otras solicitudes web comenzaron a funcionar bien de nuevo. Basándome en mi lectura en otro lugar, aprendí algunas cosas:

Esta es una configuración global en su dominio de aplicación, y si tiene actividad concurrente, no puede establecerla de manera confiable en un solo valor, realizar su acción y luego restablecerla. Otra acción puede tener lugar durante esa pequeña ventana y ser impactada.
La configuración correcta es dejarlo por defecto. Esto permite que .NET continúe usando el valor predeterminado más seguro a medida que transcurre el tiempo y actualice los marcos. Establecerlo en TLS12 (que es el más seguro a partir de este escrito) funcionará ahora, pero en 5 años puede comenzar a causar problemas misteriosos.
Si realmente necesita establecer un valor, debe considerar hacerlo en una aplicación especializada o appdomain por separado y encontrar una manera de hablar entre él y su grupo principal. Debido a que es un valor global único, tratar de administrarlo dentro de un grupo de aplicaciones ocupado solo generará problemas. Esta respuesta: https://.com/a/26754917/7656 proporciona una posible solución mediante un proxy personalizado. (Tenga en cuenta que no lo he implementado personalmente.)

La solución a esto, en .NET 4.5 es

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Si no tienes .NET 4.5 entonces usa

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

Mientras este sea un enlace relativamente "en vivo", pensé que agregaría una nueva opción. Esa posibilidad es que el servicio ya no es compatible con SSL 3.0 debido al problema con el ataque de Poodle. Echa un vistazo a la declaración de Google sobre esto. Encontré este problema con varios servicios web a la vez y me di cuenta de que algo tenía que estar pasando. Cambié a TLS 1.2 y todo está funcionando de nuevo.

http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

Otra posibilidad es la importación incorrecta de certificados en la caja. Asegúrese de seleccionar la casilla de verificación cercada. Inicialmente no lo hice, por lo que el código estaba agotando el tiempo o lanzando la misma excepción, ya que no se pudo localizar la clave privada.

Otra posible causa de la The request was aborted: Could not create SSL/TLS secure channel error de The request was aborted: Could not create SSL/TLS secure channel es una discrepancia entre los valores de cipher_suites configurados de la PC de su cliente y los valores que el servidor está configurado como dispuesto y capaz de aceptar . En este caso, cuando su cliente envía la lista de valores cipher_suites que puede aceptar en su mensaje inicial de "negociación de negociación / negociación de SSL", el servidor ve que ninguno de los valores proporcionados es aceptable y puede devolver una "Alerta "en lugar de continuar con el paso" Servidor Hola "del protocolo de enlace SSL.

Para investigar esta posibilidad, puede descargar Microsoft Message Analyzer y usarlo para ejecutar un seguimiento de la negociación SSL que se produce cuando intenta establecer una conexión HTTPS con el servidor (en su aplicación C #).

Si puede establecer una conexión HTTPS exitosa desde otro entorno (por ejemplo, la máquina con Windows XP que mencionó, o posiblemente al ingresar a la URL de HTTPS en un navegador que no sea de Microsoft y que no use la configuración de la suite de cifrado del sistema operativo, como Chrome o Firefox), ejecute otra traza del Analizador de mensajes en ese entorno para capturar lo que sucede cuando la negociación SSL se realiza correctamente.

Con suerte, verá alguna diferencia entre los dos mensajes de saludo del cliente que le permitirán identificar exactamente qué es lo que la falla en la negociación de SSL está causando que falle. Entonces debería poder realizar cambios de configuración en Windows que le permitan tener éxito. IISCrypto es una gran herramienta para usar para esto (incluso para PC cliente, a pesar del nombre "IIS").

Las siguientes dos claves de registro de Windows rigen los valores de cipher_suites que usará su PC:

HKLM / SOFTWARE / Policies / Microsoft / Cryptography / Configuration / SSL / 00010002
HKLM / SYSTEM / CurrentControlSet / Control / Cryptography / Configuration / Local / SSL / 00010002

Aquí hay un resumen completo de cómo investigué y resolví una instancia de esta variedad del problema Could not create SSL/TLS secure channel : http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in-windows.html

Prueba esto:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Puede intentar instalar un certificado de demostración (algunos proveedores de SSL los ofrecen de forma gratuita durante un mes) para asegurarse de que el problema esté relacionado con la validez del certificado o no.

Si está ejecutando su código desde Visual Studio, intente ejecutar Visual Studio como administrador. Arreglado el problema para mí.

Tenía este mismo problema y encontré que esta respuesta funcionó correctamente para mí. La clave es 3072. Este enlace proporciona los detalles sobre la corrección ''3072''.

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072; XmlReader r = XmlReader.Create(url); SyndicationFeed albums = SyndicationFeed.Load(r);

En mi caso, dos feeds requerían la solución:

https://www.fbi.gov/feeds/fbi-in-the-news/atom.xml https://www.wired.com/feed/category/gear/latest/rss

Tuve este problema al intentar golpear https://ct.mob0.com/Styles/Fun.png , que es una imagen distribuida por CloudFlare en su CDN que admite cosas locas como SPDY y extraños certificados SSL de redireccionamiento.

En lugar de especificar Ssl3 como en la respuesta de Simons, pude arreglarlo bajando a Tls12 de esta manera:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png");

Tuve este problema porque mi web.config tenía:

<httpRuntime targetFramework="4.5.2" />

y no:

<httpRuntime targetFramework="4.6.1" />