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, usamos el siguiente código que tomamos 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 funcionó bien con algo similar a lo que escribí anteriormente. La única "diferencia importante" que encontramos es que yo uso Windows 7 y él utiliza 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 debes 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.
La solución a esto, en .NET 4.5 es
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
Si no tiene .NET 4.5, utilice
ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
Asegúrese de que la configuración de ServicePointManager esté realizada antes de crear HttpWebRequest; de lo contrario, no funcionará.
Obras:
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;
Nota: Varias de las respuestas más votadas aquí recomiendan configurar ServicePointManager.SecurityProtocol, pero Microsoft desaconseja explícitamente hacerlo . A continuación, analizo la causa típica de este problema y las mejores prácticas para resolverlo.
Una de las principales causas de este problema es la versión activa de .NET Framework. La versión del tiempo de ejecución de .NET Framework afecta qué protocolos de seguridad están habilitados de forma predeterminada.
- En los sitios ASP.NET, la versión del tiempo de ejecución del marco a menudo se especifica en web.config. (vea abajo)
- En otras aplicaciones, la versión en tiempo de ejecución suele ser la versión para la que se creó el proyecto, independientemente de si se ejecuta en una máquina con una versión .NET más reciente.
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:
| Versión del marco | Protocolos predeterminados |
|---|---|
| 4.5 y anteriores | SSL 3.0, TLS 1.0 |
| 4.6.x | TLS 1.0, 1.1, 1.2, 1.3 |
| 4.7+ | Valores predeterminados del sistema (SO) |
Para las versiones anteriores, su kilometraje puede variar un poco según los tiempos de ejecución de .NET instalados en el sistema. Por ejemplo, podría darse una situación en la que esté utilizando un marco muy antiguo y no se admita TLS 1.0, o que no se admita 4.6.x y TLS 1.3.
La documentación de Microsoft recomienda encarecidamente utilizar 4.7+ y los valores predeterminados del sistema:
Le recomendamos que:
- Apunte a .NET Framework 4.7 o versiones posteriores en sus aplicaciones. Apunte a .NET Framework 4.7.1 o versiones posteriores en sus aplicaciones WCF.
- No especifique la versión TLS. Configure su código para permitir que el sistema operativo decida la versión de TLS.
- Realice una auditoría de código exhaustiva para verificar que no esté especificando una versión TLS o SSL.
Para sitios ASP.NET: verifique la targetFrameworkversión en su <httpRuntime>elemento, ya que esto (cuando esté presente) determina qué tiempo de ejecución utiliza realmente su sitio:
<httpRuntime targetFramework="4.5" />
Mejor:
<httpRuntime targetFramework="4.7" />
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 bajando a Tls12 de esta manera:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png");
