tls solicitud seguro puede para net información establecer crear con canal autoridad anulada adicional c# ssl https

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



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

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

Aquí está mi código de muestra, que he escrito en base a estas soluciones: ¿ Permitir certificados SSL no confiables con HttpClient C # ¿Ignorar errores de 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)

Encontré este hilo porque también tuve el error No se pudo crear el 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 me ayudó.

Finalmente, me topé con la causa de mi problema: el servidor con el que me estaba contactando requería la autenticación del certificado del cliente.

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

$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 que tenga mi sabor particular de este problema.

Hemos estado resolviendo el mismo problema hoy, y todo lo que necesita hacer es aumentar la versión de 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;

Lo está haciendo bien con ServerCertificateValidationCallback. Este no es el problema que estás enfrentando. El problema que enfrenta es muy probablemente 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), uso 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;

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

Windows® 8

Para borrar su caché 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 IP de Windows enjuagó con éxito la caché de resolución de DNS.

Windows® 7

Para borrar su caché 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 enjuagó con éxito la caché de resolución de DNS.

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

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

Y, sin embargo, seguí recibiendo el mismo error "La solicitud fue cancelada: no se pudo crear el canal seguro SSL / TLS". Intentaba conectarme a algunos servidores de voz más antiguos con interfaces API SOAP HTTPS (es decir, correo de voz, sistemas telefónicos 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 SecurityProtocols haría el truco aquí, pero no fue así. La única forma en que podía forzar la conexión era incluir SOLO el protocolo Ssl3 y no otros:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Luego, la conexión continúa, 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 te encuentras con esto en algunos sitios / servidores antiguos, vale la pena intentarlo.