La solicitud fue cancelada: no se pudo crear un canal seguro SSL / TLS

No podemos conectarnos a un servidor HTTPS WebRequestdebido 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, utilizamos 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?

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

Si bien 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

Según lo mencionado por Robin French; si tiene este problema mientras configura 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.

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

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Si no tiene .NET 4.5, use

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

Asegúrese de que la configuración de ServicePointManager se realice antes de crear 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;

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

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

En el paso 2 en más información

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

El error es genérico y hay muchas razones por las cuales la negociación SSL / TLS puede fallar. El más común es un certificado de servidor no válido o caducado, 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 un conjunto de cifrados no admitidos por su cliente, puede tener una deriva de tiempo demasiado grande para que el apretón de manos tenga éxito y muchas más razones.

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

Consulte también Cómo habilitar el registro de eventos de Schannel .

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

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

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

Después de muchas horas con este mismo problema, descubrí que la cuenta ASP.NET con la que se ejecutaba el servicio del cliente no tenía acceso al certificado. Lo arreglé yendo al grupo de aplicaciones IIS con el que se ejecuta la aplicación web, yendo a Configuración avanzada y cambiando la identidad a la LocalSystemcuenta deNetworkService .

Una mejor solución es hacer que el certificado funcione con la NetworkServicecuenta predeterminada , pero esto funciona para pruebas funcionales rápidas.

El enfoque con la configuración

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Parece estar bien, porque Tls1.2 es la última versión del protocolo seguro. Pero decidí profundizar y responder si realmente necesitamos codificarlo.

Especificaciones: Windows Server 2012R2 x64.

Desde Internet se dice que .NetFramework 4.6+ debe usar Tls1.2 por defecto. Pero cuando actualicé mi proyecto a 4.6 no sucedió nada. He encontrado información que dice que necesito hacer algunos cambios manualmente para habilitar Tls1.2 de forma predeterminada

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

Pero la actualización propuesta de Windows no funciona para la versión R2

Pero lo que me ayudó es agregar 2 valores al registro. Puede usar el siguiente script PS para que se agreguen automáticamente

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

Eso es lo que estaba buscando. Pero aún así no puedo responder a la pregunta de por qué NetFramework 4.6+ no establece esto ... ¿Valor de protocolo automáticamente?

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

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

Otra posibilidad es la importación incorrecta de certificados en la caja. Asegúrese de seleccionar la casilla de verificación encerrada. Inicialmente no lo hice, por lo que el código se estaba agotando o arrojaba la misma excepción ya que no se podía encontrar la clave privada.

La excepción "La solicitud se canceló: no se pudo crear el canal seguro SSL / TLS" puede ocurrir si el servidor devuelve un HTTP 401 no autorizado respuesta a la solicitud HTTP.

Puede determinar si esto está sucediendo activando el registro System.Net de 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 de 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, lo que a su vez condujo a la excepción "No se pudo crear el canal seguro SSL / TLS".

Otra posible causa del The request was aborted: Could not create SSL/TLS secure channelerror es una falta de coincidencia entre los valores configurados de cipher_suites de su PC 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 saludo / negociación SSL "Cliente Hola", el servidor ve que ninguno de los valores proporcionados son aceptables y puede devolver una "Alerta" "respuesta en lugar de continuar con el paso" Server Hello "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 ocurre cuando intenta establecer una conexión HTTPS con el servidor (en su aplicación C #).

Si puede realizar una conexión HTTPS exitosa desde otro entorno (por ejemplo, la máquina con Windows XP que mencionó) o posiblemente presionando la URL HTTPS en un navegador que no sea de Microsoft que no utiliza la configuración del conjunto de cifrado del sistema operativo, como Chrome o Firefox), ejecute otro seguimiento de Message Analyzer en ese entorno para capturar lo que sucede cuando la negociación SSL tiene éxito.

Afortunadamente, verá alguna diferencia entre los dos mensajes de saludo de cliente que le permitirán determinar exactamente qué sucede con el fracaso de la negociación SSL que está causando que falle. Entonces debería poder hacer cambios en la configuración de 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 gobiernan los valores de cipher_suites que usará su PC:

• HKLM \ SOFTWARE \ Políticas \ Microsoft \ Criptografía \ Configuración \ 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 Could not create SSL/TLS secure channelproblema: http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in-windows.html

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

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Esto es realmente malo No solo le indica a .NET que use un protocolo inseguro, sino que esto afecta a cada nueva solicitud de WebClient (y similar) que se realice 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 WebClient, como hablar con un servicio web externo, sí lo son).

En mi caso, en realidad no era necesario, por lo que podría eliminar la declaración y todas mis otras solicitudes web comenzaron a funcionar bien nuevamente. Basado en mi lectura en otra parte, aprendí algunas cosas:

• Esta es una configuración global en su dominio de aplicación, y si tiene actividad concurrente, no puede establecerlo de manera confiable, realizar su acción y luego volver a configurarlo. Otra acción puede tener lugar durante esa pequeña ventana y verse afectada.
• La configuración correcta es dejarlo por defecto. Esto permite que .NET continúe usando el valor predeterminado más seguro a medida que pasa el tiempo y actualiza 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, debería considerar hacerlo en una aplicación especializada o dominio de aplicación 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://stackoverflow.com/a/26754917/7656 proporciona una posible solución a través de un proxy personalizado. (Tenga en cuenta que no lo he implementado personalmente).

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

<httpRuntime targetFramework="4.5.2" />

y no:

<httpRuntime targetFramework="4.6.1" />

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

Si establece el valor de WebRequest.Timeouta 0, esta es la excepción que se genera. A continuación se muestra el código que tenía ... (Excepto en lugar de un código rígido 0para el valor de tiempo de espera, tenía un parámetro que se configuró inadvertidamente 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 ...

La respuesta más votada probablemente sea suficiente para la mayoría de las personas. Sin embargo, en algunas circunstancias, puede continuar recibiendo el error "No se pudo crear el canal seguro SSL / TLS" incluso después de forzar TLS 1.2. Si es así, puede consultar este útil artículo.para pasos adicionales de solución de problemas. Para resumir: independientemente del problema de la versión TLS / SSL, el cliente y el servidor deben acordar un "conjunto de cifrado". Durante la fase de "protocolo de enlace" de la conexión SSL, el cliente enumerará sus conjuntos de cifrado compatibles para que el servidor los compare con su propia lista. Pero en algunas máquinas con Windows, ciertas suites de cifrado comunes pueden haberse deshabilitado (aparentemente debido a intentos bien intencionados de limitar la superficie de ataque), lo que disminuye la posibilidad de que el cliente y el servidor acuerden una suite de cifrado. Si no pueden aceptar, entonces puede ver el "código de alerta fatal 40" en el visor de eventos y "No se pudo crear el canal seguro SSL / TLS" en su programa .NET.

El artículo mencionado anteriormente explica cómo enumerar todos los conjuntos de cifrado potencialmente compatibles de una máquina y habilitar conjuntos de cifrado adicionales a través del Registro de Windows. Para ayudar a verificar qué conjuntos de cifrado están habilitados en el cliente, intente visitar esta página de diagnóstico en MSIE. (El uso del rastreo de System.Net puede dar resultados más definitivos). Para verificar qué conjuntos de cifrado son compatibles con el servidor, pruebe esta herramienta en línea (suponiendo que el servidor sea accesible por Internet). No hay que decir que las ediciones del Registro deben realizarse con precaución , especialmente cuando se trata de redes. (¿Es su máquina una VM alojada remotamente? Si tuviera que romper la red, ¿sería accesible la VM?)

En el caso de mi empresa, habilitamos varias suites "ECDHE_ECDSA" adicionales a través de la edición del Registro, para solucionar un problema inmediato y evitar futuros problemas. Pero si no puede (o no quiere) editar el Registro, entonces se le ocurren numerosas soluciones (no necesariamente bonitas). Por ejemplo: su programa .NET podría delegar su tráfico SSL a un programa Python separado (que puede funcionar por sí mismo, por la misma razón que las solicitudes de Chrome pueden tener éxito cuando las solicitudes de MSIE fallan en una máquina afectada).

Una de las principales causas de este problema es la versión activa de .NET Framework. La versión de .NET Framework Runtime afecta qué protocolos de seguridad están habilitados de manera predeterminada.

No parece haber ninguna documentación autorizada sobre cómo funciona específicamente en diferentes versiones, pero parece que los valores predeterminados se determinan más o menos de la siguiente manera:

• .NET Framework 4.5 y versiones anteriores: SSL 3.0, TLS 1.0
• .NET Framework 4.6.x - TLS 1.0, 1.1, 1.2, 1.3
• .NET Framework 4.7+ - Valores predeterminados del sistema (SO)

(Para las versiones anteriores, su kilometraje puede variar en función de los tiempos de ejecución de .NET instalados en el sistema. Por ejemplo, podría haber una situación en la que esté utilizando un marco muy antiguo y TLS 1.0 no sea compatible, o use 4.6. xy TLS 1.3 no es compatible)

La documentación de Microsoft recomienda encarecidamente usar 4.7+ y los valores predeterminados del sistema:

Recomendamos que usted:

• Diríjase a .NET Framework 4.7 o versiones posteriores en sus aplicaciones. Diríjase a .NET Framework 4.7.1 o versiones posteriores en sus aplicaciones WCF.
• No especifique la versión de TLS. Configure su código para permitir que el sistema operativo decida sobre la versión TLS.
• Realice una auditoría de código exhaustiva para verificar que no está especificando una versión TLS o SSL.

Para los sitios ASP.NET , verifique la versión de .NET Framework en su <httpRuntime>elemento, ya que esto determina qué tiempo de ejecución realmente utiliza su sitio:

<httpRuntime targetFramework="4.5" />

Mejor:

<httpRuntime targetFramework="4.7" />

Este me está funcionando en el cliente web 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;
        }
    }

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

Esto se puede configurar en:

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

Desplácese hacia abajo hasta "Seguridad" y elija entre

• Use SSL 2.0
• Use SSL 3.0
• Use TLS 1.0
• Utilice TLS 1.1
• Utilice TLS 1.2

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 le di este permiso, el error desapareció

1. mmc
2. certificados
3. Expandir a personal
4. seleccione cert
5. botón derecho del ratón
6. Todas las tareas
7. Administrar claves privadas
8. Añadir

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

He luchado con este problema todo el día.

Cuando creé un nuevo proyecto con .NET 4.5 finalmente lo puse a trabajar.

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

No es extraño ningún otro mensaje de error pero "La solicitud fue cancelada: no se pudo crear el canal seguro SSL / TLS". surgió este error

System.Net.WebException: la solicitud se anuló: 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" para el 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

Prueba esto:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Esto solucionó para mí, agregar el servicio de red a los permisos Haga clic derecho en el certificado> Todas las tareas> Administrar claves privadas ...> Agregar ...> Agregar "Servicio de red".

El problema para mí fue que estaba tratando de 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 dar acceso ASP.NET a una clave privada en un certificado en el almacén de certificados?

Estaba teniendo 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 fuentes requieren la solución:

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

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

Esencialmente, 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 un canal seguro SSL / TLS".

Hay tres arreglos.

1) Parchee 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 conocimiento que publiqué.

Otra posibilidad es que el código que se ejecuta no tenga los permisos necesarios.

En mi caso, recibí este error al usar el depurador de Visual Studio para probar una llamada a un servicio web. Visual Studio no se estaba ejecutando como administrador, lo que provocó esta excepción.

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