No se pudo establecer una relación de confianza para el canal seguro SSL/TLS: SOAP
Tengo una llamada de servicio web simple, generada por una aplicación de Windows .NET (C#) 2.0, a través del proxy de servicio web generado por Visual Studio, para un servicio web también escrito en C# (2.0). Esto ha funcionado durante varios años y continúa haciéndolo en la docena de lugares donde se ejecuta.
Una nueva instalación en un sitio nuevo tiene un problema. Al intentar invocar el servicio web, falla y aparece el mensaje:
No se pudo establecer una relación de confianza para el canal seguro SSL/TLS
La URL del servicio web utiliza SSL (https://), pero ha estado funcionando durante mucho tiempo (y continúa haciéndolo) desde muchas otras ubicaciones.
¿Dónde miro? ¿Podría ser esto un problema de seguridad entre Windows y .NET exclusivo de esta instalación? Si es así, ¿dónde establezco relaciones de confianza? ¡Estoy perdido!
Los siguientes fragmentos solucionarán el caso en el que haya algún problema con el certificado SSL en el servidor al que está llamando. Por ejemplo, puede que esté autofirmado o que el nombre de host entre el certificado y el servidor no coincida.
Esto es peligroso si llama a un servidor fuera de su control directo, ya que ya no puede estar tan seguro de estar hablando con el servidor al que cree que está conectado. Sin embargo, si está tratando con servidores internos y obtener un certificado "correcto" no es práctico, utilice lo siguiente para decirle al servicio web que ignore los problemas del certificado y siga adelante con valentía.
Los dos primeros usan expresiones lambda, el tercero usa código regular. El primero acepta cualquier certificado. Los dos últimos al menos verifican que el nombre de host en el certificado sea el esperado.
... espero que te resulte útil
//Trust all certificates
System.Net.ServicePointManager.ServerCertificateValidationCallback =
((sender, certificate, chain, sslPolicyErrors) => true);
// trust sender
System.Net.ServicePointManager.ServerCertificateValidationCallback
= ((sender, cert, chain, errors) => cert.Subject.Contains("YourServerName"));
// validate cert by calling a function
ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(ValidateRemoteCertificate);
// callback used to validate the certificate in an SSL conversation
private static bool ValidateRemoteCertificate(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors policyErrors)
{
bool result = cert.Subject.Contains("YourServerName");
return result;
}
La solución muy simple "abarca todo" es la siguiente:
System.Net.ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
La solución de sebastian-castaldi es un poco más detallada.
Pensamientos (basados en el dolor del pasado):
- ¿Tiene DNS y línea de visión con el servidor?
- ¿Estás usando el nombre correcto del certificado?
- ¿El certificado sigue siendo válido?
- ¿Un balanceador de carga mal configurado está arruinando las cosas?
- ¿La nueva máquina
servidortiene el reloj configurado correctamente (es decir, para que la hora UTC sea correcta [ignore la hora local, es en gran medida irrelevante])? Esto ciertamente es importante para WCF, por lo que puede afectar el SOAP normal. - ¿Existe algún problema con la cadena de confianza de los certificados? Si navega desde el servidor al servicio SOAP, ¿puede obtener SSL?
- En relación con lo anterior: ¿se ha instalado el certificado en la ubicación correcta? (es posible que necesite una copia en Autoridades de certificación raíz de confianza)
- ¿Está configurado correctamente el proxy a nivel de máquina del servidor? (que es diferente al proxy del usuario); consulte proxycfg para XP/2003 (no estoy seguro acerca de Vista, etc.)
