No podemos conectarnos a un servidor HTTPS utilizando WebRequest
debido a este mensaje de error:
La solicitud fue abortada: No se ha podido crear un canal seguro SSL/TLS.
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 otro post 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 hicimos pruebas hace unas semanas y funcionaba bien con algo similar a lo que escribí arriba. La única "gran diferencia" que hemos encontrado es que yo' estoy usando Windows 7 y él estaba usando Windows XP. ¿Cambia eso algo?
El problema que tienes es que el usuario de aspNet no tiene acceso al certificado. Tiene 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
EDIT: En las versiones más recientes de IIS, esta función está integrada en la herramienta de gestión de certificados, y se puede acceder a ella haciendo clic con el botón derecho del ratón en el certificado y utilizando la opción de gestión de claves privadas. Más detalles aquí: https://serverfault.com/questions/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 que la negociación SSL/TLS puede fallar. La más común es un certificado de servidor inválido o caducado, y usted se encargó de eso proporcionando su propio gancho de validación del certificado del servidor, pero no es necesariamente la única razón. El servidor puede requerir autenticación mutua, puede estar configurado con un conjunto de cifrados no soportados por su cliente, puede tener una deriva de tiempo demasiado grande para que el handshake 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 SSPI responsable de SSL y TLS y su cliente lo utilizará para el handshake. Echa un vistazo a Herramientas y configuración de TLS/SSL.
También vea Cómo habilitar el registro de eventos de Schannel.