No se pudo crear un canal seguro SSL / TLS, a pesar de configurar ServerCertificateValidationCallback

Estoy intentando establecer una conexión SSL / TLS para probar el servidor con certificado autofirmado . La comunicación a través de un canal inseguro funcionó sin problemas.

Aquí está mi código de muestra, que escribí en base a estas soluciones: Permitir certificados SSL que no son de confianza con HttpClient C # ¿Ignorar los errores del certificado? Cliente .NET que se conecta a la API web ssl

ServicePointManager.ServerCertificateValidationCallback += (sender, cert, chain, sslPolicyErrors) => true;

var c = new HttpClient();
var r = c.GetAsync("https://10.3.0.1:8443/rest/v1").Result;
if (r.IsSuccessStatusCode)
{
    Log.AddMessage(r.Content.Get<string>());
}
else
{
    Log.AddMessage(string.Format("{0} ({1})", (int)r.StatusCode, r.ReasonPhrase));
}

también probé esto:

var handler = new WebRequestHandler();
handler.ServerCertificateValidationCallback = delegate { return true; };
var c = new HttpClient(handler);
...

y esto

ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };

pero cada vez tengo una excepción:

InnerException: System.Net.Http.HttpRequestException
   _HResult=-2146233088
   _message=An error occurred while sending the request.
   HResult=-2146233088
   IsTransient=false
   Message=An error occurred while sending the request.
   InnerException: System.Net.WebException
        _HResult=-2146233079
        _message=The request was aborted: Could not create SSL/TLS secure channel.
        HResult=-2146233079
        IsTransient=false
        Message=The request was aborted: Could not create SSL/TLS secure channel.
        Source=System
        StackTrace:
             at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
             at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)
        InnerException: 

¿Qué hago mal? Por qué no puedo conectarme a este servidor (que tiene un certificado autofirmado no válido)

Lo está haciendo bien con ServerCertificateValidationCallback. Este no es el problema al que se enfrenta. Lo más probable es que el problema al que se enfrenta sea la versión del protocolo SSL / TLS.

Por ejemplo, si su servidor ofrece solo SSLv3 y TLSv10 y su cliente necesita TLSv12, recibirá este mensaje de error. Lo que debe hacer es asegurarse de que tanto el cliente como el servidor tengan una versión de protocolo común compatible.

Cuando necesito un cliente que pueda conectarse a tantos servidores como sea posible (en lugar de ser lo más seguro posible) utilizo esto (junto con la configuración de la devolución de llamada de validación):

  ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

Hemos estado resolviendo el mismo problema hoy, y todo lo que necesita hacer es aumentar la versión en tiempo de ejecución de .NET

4.5.2 no funcionó para nosotros con el problema anterior, mientras que 4.6.1 estaba bien

Si necesita mantener la versión .NET, configure

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

Solo como seguimiento para cualquiera que todavía se encuentre con esto, agregué las opciones ServicePointManager.SecurityProfile como se indica en la solución:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

Y, sin embargo, seguí obteniendo el mismo error "La solicitud fue cancelada: No se pudo crear el canal seguro SSL / TLS". Estaba intentando conectarme a algunos servidores de voz más antiguos con interfaces HTTPS SOAP API (es decir, correo de voz, sistemas de telefonía IP, etc. instalados hace años). Estos solo admiten conexiones SSL3, ya que se actualizaron por última vez hace años.

Uno pensaría que incluir SSl3 en la lista de protocolos de seguridad funcionaría aquí, pero no fue así. La única forma en que podía forzar la conexión era incluir SOLO el protocolo Ssl3 y ningún otro:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Luego, la conexión se realiza; me parece un error, pero esto no comenzó a arrojar errores hasta hace poco en las herramientas que proporciono para estos servidores que han estado disponibles durante años.Creo que Microsoft ha comenzado a implementar cambios en el sistema que han actualizado esto. comportamiento para forzar conexiones TLS a menos que no haya otra alternativa.

De todos modos, si todavía se encuentra con esto en algunos sitios / servidores antiguos, vale la pena intentarlo.

mueva esta línea: ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

Antes de esta línea: HttpWebRequest request = (HttpWebRequest) WebRequest.Create (uri);

Publicación original: KB4344167 actualización de seguridad rompe el código TLS

En mi caso, TLS1_2 estaba habilitado tanto en el cliente como en el servidor, pero el servidor estaba usando MD5 mientras el cliente lo deshabilitaba. Entonces, pruebe tanto el cliente como el servidor en http://ssllabs.com o pruebe usando openssl / s_client para ver qué está sucediendo. Además, verifique el cifrado seleccionado usando Wireshark.

TLS 1.0 y 1.1 ahora son End of Life. Se actualizó un paquete en nuestro servidor web de Amazon y comenzamos a recibir este error.

La respuesta está arriba, pero no debería usar tlso tls11más.

Específicamente para ASP.Net, agregue esto a uno de sus métodos de inicio.

        public Startup()
        {
            ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls12;

pero estoy seguro de que algo como esto funcionará en muchos otros casos.

Si está utilizando un nuevo nombre de dominio, y ha hecho todo lo anterior y aún recibe el mismo error, verifique si borró la caché de DNS en su PC. Borre su DNS para obtener más detalles.

Windows® 8

Para borrar su caché de DNS si usa Windows 8, realice los siguientes pasos:

En su teclado, presione Win + X para abrir el menú WinX.

Haga clic con el botón derecho en Símbolo del sistema y seleccione Ejecutar como administrador.

Ejecute el siguiente comando:

ipconfig / flushdns

Si el comando tiene éxito, el sistema devuelve el siguiente mensaje:

La configuración de IP de Windows vació correctamente la caché de resolución de DNS.

Windows® 7

Para borrar su caché de DNS si usa Windows 7, realice los siguientes pasos:

Haga clic en Inicio.

Ingrese cmd en el cuadro de texto de búsqueda del menú Inicio.

Haga clic con el botón derecho en Símbolo del sistema y seleccione Ejecutar como administrador.

Ejecute el siguiente comando:

ipconfig / flushdns

Si el comando tiene éxito, el sistema devuelve el siguiente mensaje: La configuración de IP de Windows descargó correctamente la caché de resolución de DNS.

Me encontré con este hilo porque también tuve el error No se pudo crear un canal seguro SSL / TLS. En mi caso, estaba intentando acceder a una API REST de configuración de Siebel desde PowerShell usando Invoke-RestMethod, y ninguna de las sugerencias anteriores ayudó.

Finalmente me encontré con la causa de mi problema: el servidor con el que me estaba comunicando requería autenticación de certificado de cliente.

Para que las llamadas funcionen, tuve que proporcionar el certificado del cliente (incluida la clave privada) con el -Certificateparámetro:

$Pwd = 'certificatepassword'
$Pfx = New-Object -TypeName 'System.Security.Cryptography.X509Certificates.X509Certificate2'
$Pfx.Import('clientcert.p12', $Pwd, 'Exportable,PersistKeySet')
Invoke-RestMethod -Uri 'https://your.rest.host/api/' -Certificate $Pfx -OtherParam ...

Espero que mi experiencia pueda ayudar a alguien más que tenga mi sabor particular de este problema.