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


432

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?



51
¡Es 2018 y esta pregunta se ha visto 308,056 veces, pero todavía no hay una solución adecuada para esto! Recibo este problema al azar y ninguna de las correcciones mencionadas aquí o en cualquier otro hilo ha resuelto mi problema.
Nigel Fds

3
@NigelFds El error The request was aborted: Could not create SSL/TLS secure channeles muy genérico. Básicamente dice, "la inicialización de la conexión SSL / TLS / HTTPS falló por una de las muchas razones posibles". Entonces, si lo obtiene regularmente en una situación específica, su mejor opción es hacer una pregunta específica con detalles específicos sobre esa situación. Y revisando el Visor de eventos para más información. Y / o habilite la depuración del lado del cliente .NET para obtener más detalles (¿no es confiable el certificado del servidor? ¿Hay una falta de coincidencia de cifrado? ¿No coincide la versión del protocolo SSL / TLS? Etc.).
MarnixKlooster ReinstateMonica

44
@MarnixKlooster Ya he comprobado todo eso, no puede ser un problema con el certificado como si lo volviera a intentar, funciona. Y dudo que pueda hacer esta pregunta en SO sin que alguien venga y la marque como duplicado o algo así.
Nigel Fds

1
Estoy luchando contra este problema tal vez por cuarta vez. La misma base de código que estoy ejecutando funciona bien en la producción y también en el entorno de desarrollo de algunos de mis colegas desarrolladores. La última vez, recibí instrucciones para agregar un valor de registro Computer \ HKEY_LOCAL_MACHINE \ SOFTWARE \ WOW6432Node \ Microsoft \ .NETFramework \ v4.7.02046 \ SchUseStrongCrypto [DWORD] = 1. Y funcionó durante un tiempo. Empecé a trabajar en un proyecto diferente por un tiempo y ahora vuelvo a este proyecto y la solicitud falla nuevamente, incluso con esta corrección de clave de registro. Muy molesto.
Miguel

Respuestas:


598

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.


55
Bajar a SecurityProtocolType.Tls12 realmente solucionó este problema para mí. Vea mi respuesta a continuación.
Bryan Legend

24
SSLv3 tiene 18 años y ahora es susceptible al exploit POODLE, como @LoneCoder recomienda SecurityProtocolType.Tls12 es el reemplazo adecuado para SecurityProtocolType.Ssl3
gary

44
SecurityProtocolType.Tls en realidad podría ser una mejor alternativa hasta un exploit se encontraron para ese (no todos los sitios son compatibles Tls12 como de la escritura)
Gary

3
PayPal ha establecido una fecha del 30 de junio de 2017 para deshabilitar SSL3 e implementar TLS1.2. Ya está aplicado en su entorno de sandbox paypal-knowledge.com/infocenter/…
Robin French

11
Mira esto también. No necesita establecerlo exclusivamente en un solo tipo, simplemente puede agregarlo también. System.Net.ServicePointManager.SecurityProtocol |= System.Net.SecurityProtocolType.Tls12;
Nae

153

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;

10
¡Gracias! Necesito usar .net 4.0 y no sabía cómo resolver esto. Esto parece funcionar aquí. :)
Fabiano

No funciona en Windows Server 2008R2 (y posiblemente también en 2012)
Misam

@billpg, lea esto para obtener una respuesta más exacta
Vikrant

Para los tipos de VB (dado que esta respuesta aparece en Google), el código equivalente esServicePointManager.SecurityProtocol = DirectCast(3072, SecurityProtocolType)
ConfusionTowers el

@Andrej Z está trabajando en .net framework 4. Gracias.
az fav

107

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;

44
¿Cuál es la diferencia entre Works y Fails que mencionaste anteriormente?
Chandy Kunhu

55
Increíble. Mi solicitud solo funcionó después del segundo intento, lo que no tenía sentido y luego vi su publicación, moví el protocolo de seguridad antes de la solicitud y listo, solucionado. Gracias @ hogarth45
deanwilliammills

2
¡Exactamente! cuando coloqué ServicePointManager justo antes de que se creara la solicitud, funcionó para mí, gracias hombre, me salvaste el día.

1
Perfecto ... esto es maravilloso
Maryam Bagheri

1
En nuestro caso, la solicitud falló por primera vez y funcionó después. ¡Eso fue exactamente por la razón establecida en esta respuesta!
Mohammad Dehghan

34

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


He intentado ejecutar winhttpcertcfg.exe ... tenga en cuenta que estoy en Windows 7. ¿Puede cambiar algo?
Simon Dugré

No estoy seguro de si está relacionado, pero esta publicación me dio la idea de ejecutar VS como administrador al hacer esta llamada desde VS y eso me solucionó el problema.
PFranchise

2
En Windows 7 y versiones posteriores, el certificado debe estar en la tienda del equipo local en lugar del usuario actual para "Administrar claves privadas"
Lukos

1
Sí, este fue mi problema. use mmc.exe, agregue el complemento de certificados (para mí elegí 'computadora local'). Haga clic con el botón derecho en el certificado, todas las tareas, administre las claves privadas. Agregue 'todos' (para el desarrollador local, esto es más fácil; obviamente, el producto necesita su grupo / usuario explícito de aplicaciones del sitio web de IIS)
Ian Yates

@ Ian Yates, esta solución solo funcionó para mí (y)
Usman Younas

31

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 .


¿Dónde está el camino de Schannel event loggingen Ventanas 07/08/10 ?
PreguntonCojoneroCabrón

solucionar problemas de TLS / SSL programáticamente en C #?
Kiquenet

27

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");

Gracias Lone ... esto es una locura, ya que parece haber muchas posibilidades diferentes de problemas dependiendo de la situación ... Y, como puedo ver, no hay documentación real de eso. Bueno, gracias por señalar a alguien que puede experimentar el mismo problema.
Simon Dugré

Esto funcionó para mí. Me enfrenté al error cuando cambié de la LAN de la oficina a mi red doméstica. ¡El mismo código, la misma computadora portátil!
Amal

¿Obtiene el error siempre (en todas las solicitudes) o algunas veces ?
PreguntonCojoneroCabrón

24

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.


3
Esta respuesta debería tener más votos positivos. Después de una semana de investigación, esta es la única solución que funcionó para mí. ¡¡Gracias!!
user224567893

Esto funcionó para mí. perfecto gracias.
Emy Estadísticas

18

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?


17

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;

8
No recomendaría el protocolo SSL3 agregado.
Peter de Bruijn

SSL3 tiene un grave problema de seguridad llamado 'Poodle'.
Peter de Bruijn

@PeterdeBruijn Tls and Tls11son obsoletos ?
Kiquenet

1
@Kiquenet: sí. A partir de junio de 2018, PCI (Payment Card Industries) no permitirá protocolos inferiores a TLS1.2. (Esto se programó originalmente para 06/2017 pero se pospuso por un año)
GlennG

Hay cinco protocolos en la familia SSL / TLS: SSL v2, SSL v3, TLS v1.0, TLS v1.1 y TLS v1.2 : github.com/ssllabs/research/wiki/… ¿ SSL v2 unsecure, SSL v3 is insecure when used with HTTP (the POODLE attack), TLS v1.0, TLS v1.1 obsoletes Solo será una opción válida ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12?
Kiquenet

14

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.

cuadro de diálogo de importación de certificado


Un cliente seguía teniendo que volver a instalar el certificado para poder usar un programa cliente. Una y otra vez tendrían que volver a instalar el certificado antes de usar el programa. Espero que esta respuesta solucione ese problema.
Pangamma

11

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".


1
Mi programador de tareas se ejecuta todos los días (no los fines de semana). Me sale el mismo error, pero a veces ( 2 errors in 2 months). Cuando recibo el error, unos minutos más tarde vuelvo a intentarlo manualmente y todo está bien.
Kiquenet

10

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


1
En mi caso, esta respuesta es útil. Además, como sospechaba que mi PC cliente se había perdido algunas suites de cifrado, tomé un acceso directo e instalé esta actualización de Windows directamente para probar suerte ( support.microsoft.com/en-hk/help/3161639 , necesita reiniciar Windows) antes de comenzar realmente Message Analyzer, y resultó que tuve suerte y resolvió mi problema, ahorrándome una búsqueda.
sken130

1
Tenga en cuenta que cuando prueba un enlace HTTPS en navegadores como Firefox, incluso si obtiene un cifrado diferente al proporcionado por cualquier actualización de Windows, vale la pena probar la actualización de Windows, ya que la instalación de nuevos cifrados afectará la negociación del cifrado entre la PC cliente y el servidor, lo que aumenta la esperanza de encontrar una coincidencia.
sken130

Al punto responda a mi problema. Dos cosas que me ayudaron a encontrar los cambios a realizar. 1. Cipher Suites compatibles con el servidor web: ssllabs.com/ssltest 2. Cipher Suites que admiten diferentes versiones de Windows: docs.microsoft.com/en-us/windows/win32/secauthn/…
Paul B.

10

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).

2
Contrariamente a su regla general, agregaré que hay una excepción cuando DEBE configurarlo en TLS 1.2, en lugar de dejar que se ejecute el valor predeterminado. Si tiene un marco anterior a .NET 4.6 y deshabilita protocolos inseguros en su servidor (SSL o TLS 1.0 / 1.1), no puede emitir solicitudes a menos que fuerce el programa a TLS 1.2.
Paul

10

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

<httpRuntime targetFramework="4.5.2" />

y no:

<httpRuntime targetFramework="4.6.1" />

Tuve este mismo problema y agregué una respuesta más detallada a continuación, que incluye más detalles de este problema.
JLRishe

9

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 ...

2
¡Guauu! Gracias por mencionar esto. No podía creer esto en primer lugar y probé toneladas de cosas diferentes primero. Luego, finalmente, establezca el tiempo de espera en 10 segundos y la excepción desapareció. Esta es la solución para mí. (y)
derFunk

9

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).


9

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" />

8

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;
        }
    }

2
¿Reemplazar ServerCertificateValidationCallback introduciría un nuevo agujero de seguridad?

7

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

ingrese la descripción de la imagen aquí


¿Algún problema para marcarlos a todos?
Nigel Fds

no hay problemas, que yo sepa ... excepto que ya no se recomiendan SSL ... no se consideran lo suficientemente seguros.
cnom

¿Cómo hacerlo programáticamente en powershell?
Kiquenet

Esto es algo que afecta a versiones anteriores de Windows. Investigue un poco, descubra qué opciones de seguridad están actualmente en uso. A partir de hoy vea este enlace: tecadmin.net/enable-tls-on-windows-server-and-iis
Tod

7

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

7

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


¡Ay, no para mí!
benedict_w

¡Este es el único que ayudó en mi caso! ¡¡¡Gracias!!!
alexander ostrikov

6

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


55
La razón por la que esto funcionó puede deberse a que diferentes versiones de .NET admiten diferentes versiones de protocolo SSL / TLS. Más información: blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support
Jon Schneider

4

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

3
Aquí PS para edición rápida: New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value "1" -Type DWord
Tilo

2
Aquí PS para edición rápida2: New-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value "1" -Type DWord
Tilo

4

Prueba esto:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Agregué esta fila. A veces falla y me sale el mismo errorSystem.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
Joseph Katzman

4

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".


3

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?


Sí, lo mismo. Para solucionarlo, hice lo que decía la respuesta de Nick Gotch: cambié la identidad del grupo de aplicaciones a LocalSystem. Esto lo resolvió para mí.
Judá Gabriel Himango

1
Gracias por esto
Denis Pitcher

3

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

3

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é.


Además, asegúrese de configurar solo ServicePointManager.SecurityProtocol una vez en su aplicación. Descubrimos una segunda llamada en nuestra aplicación (que es bastante compleja con los ensamblajes opcionales que se cargan en tiempo de ejecución) que la configuraba en SSL3, que luego arrojó el mismo mensaje de error.
Michael Silver

3

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.


2

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ó.


1
No use enlaces en la respuesta, ya que pueden no funcionar en el futuro, señale los aspectos más relevantes en su respuesta
Rodrigo López
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.