enable - wcf service c# https

Cómo resolver "No se pudo establecer una relación de confianza para el canal seguro SSL/TLS con autoridad"

Question

Realmente pensé que tenía este problema solucionado, pero solo estaba disfrazado antes.

Tengo un servicio WCF alojado en IIS 7 usando HTTPS. Cuando navego a este sitio en Internet Explorer, funciona como un encanto, esto se debe a que he agregado el certificado al almacén de la autoridad del certificado raíz local.

Estoy desarrollando en 1 máquina, por lo que el cliente y el servidor son la misma máquina. El certificado se firma automáticamente desde el complemento de administración de IIS 7.

Continuamente obtengo este error ahora ...

No se pudo establecer una relación de confianza para el canal seguro SSL / TLS con autoridad.

... cuando se llama desde la consola del cliente.

Me di manualmente permisos y servicio de red para el certificado, usando findprivatekey y usando cacls.exe .

Traté de conectarme al servicio utilizando SOAPUI, y eso funciona, por lo que debe ser un problema en mi aplicación cliente, que es un código basado en lo que solía funcionar con http.

¿Dónde más puedo mirar parece haber agotado todas las posibilidades de por qué no puedo conectarme?

Answer 1

Acabo de arrastrar el certificado a la carpeta "Autoridades de certificación de raíz de confianza" y todo funcionó de maravilla.

Oh. Y primero agregué lo siguiente de un Símbolo del sistema de administrador:

netsh http add urlacl url=https://+:8732/Servicename user=NT-MYNDIGHET/INTERAKTIV

No estoy seguro del nombre que necesita para el usuario (¡el mío es noruego, como puede ver!): user=NT-AUTHORITY/INTERACTIVE ?

Puede ver todos los urlacl existentes emitiendo el comando: netsh http show urlacl

Answer 2

Además de las respuestas anteriores, puede encontrar este error si su cliente ejecuta una versión TLS incorrecta, por ejemplo, si el servidor solo está ejecutando TLS 1.2.

Puedes arreglarlo usando:

 ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; //tested in .NET 4.5

Answer 3

Agregue esto a su código de cliente:

ServicePointManager.ServerCertificateValidationCallback = new RemoteCertificateValidationCallback(
delegate
{
return true;
});

Answer 4

Como solución alternativa, puede agregar un controlador a ServerCertificateValidationCallback de ServerCertificateValidationCallback en el lado del cliente:

System.Net.ServicePointManager.ServerCertificateValidationCallback +=
(se, cert, chain, sslerror) =>
{
return true;
};

pero tenga en cuenta que esta no es una buena práctica ya que ignora por completo el certificado del servidor y le dice al administrador del punto de servicio que cualquier certificado es correcto, lo que puede comprometer seriamente la seguridad del cliente. Puede refinar esto y hacer alguna comprobación personalizada (para el nombre del certificado, hash, etc.). al menos puede evitar problemas durante el desarrollo al usar certificados de prueba.

Answer 5

Cuando tengo este problema es porque client.config tenía sus extremos como:

 https://myserver/myservice.svc

pero el certificado estaba esperando

 https://myserver.mydomain.com/myservice.svc

Cambiar los puntos finales para que coincida con el FQDN del servidor resuelve mi problema. Sé que esta no es la única causa de este problema.

Answer 6

Encontré el mismo problema y pude resolverlo con dos soluciones: Primero, utilicé los "Certificados" del complemento MMC para la "Cuenta de equipo" y arrastré el certificado autofirmado a la carpeta "Autoridades de certificación de raíz de confianza" . Esto significa que la computadora local (la que generó el certificado) ahora confiará en ese certificado. En segundo lugar, noté que el certificado se generó para un nombre de computadora interno, pero se accedía al servicio web con otro nombre. Esto causó una falta de coincidencia al validar el certificado. Generamos el certificado para computer.operations.local, pero accedimos al servicio web usando https://computer.internaldomain.companydomain.com . Cuando cambiamos la URL a la utilizada para generar el certificado, no obtuvimos más errores.

Tal vez solo cambiar las URL hubiera funcionado, pero al hacer que el certificado sea confiable, también evitas la pantalla roja en Internet Explorer donde te dice que no confía en el certificado.

Answer 7

Esto ocurrió al intentar conectarse al Servicio WCF a través de. el IP ej. https://111.11.111.1:port/MyService.svc mientras se usa un certificado vinculado a un nombre eg mysite.com.

El cambio a https://mysite.com:port/MyService.svc resolvió.

Answer 8

Esto ocurrió al tratar de conectarse al Servicio WCF utilizando solo el nombre de host, por ejemplo, https://host/MyService.svc al usar un certificado vinculado a un nombre, por ejemplo, host.mysite.com.

Cambiando a https://host.mysite.com/MyService.svc y esto lo resuelve.

Answer 9

Por favor, siga los siguientes pasos:

1. Abrir el enlace de servicio en IE.

2. Haga clic en la mención de error de certificado en la barra de direcciones y haga clic en Ver certificados.

3. Cheque emitido a: nombre.

4. Tome el nombre emitido y reemplace la mención de servidor local en el servicio y el nombre de la dirección base del punto final del cliente con Un nombre de dominio completo (FQDN).

Por ejemplo: https: // localhost : 203 / SampleService.svc a https: // INL-126166-.groupinfra.com : 203 / SampleService.svc

Answer 10

Solo solucioné un problema similar.

Me di cuenta de que tenía un grupo de aplicaciones que se estaba ejecutando bajo una cuenta que solo tenía permiso de lectura sobre el certificado que se utilizó.

La aplicación .NET podría recuperar correctamente el certificado, pero esa excepción se lanzó solo cuando se llamó a GetRequestStream ().

Los permisos de certificados se pueden administrar a través de la consola de MMC

Answer 11

Su problema surge porque está usando una clave autofirmada. El cliente no confía en esta clave, ni la propia clave proporciona una cadena para validar o una lista de revocación de certificados.

Tienes algunas opciones: puedes

1. desactivar la validación del certificado en el cliente (mala jugada, abundan los ataques del hombre en el medio)

2. use makecert para crear una CA raíz y cree certificados a partir de eso (muévala bien, pero todavía no hay CRL)

3. cree una CA raíz interna utilizando Windows Certificate Server u otra solución PKI y luego confíe en ese certificado raíz (un poco difícil de manejar)

4. compre un certificado SSL de una de las CA confiables (costoso)

Answer 12

Tuve un problema similar con el certificado autofirmado. Podría resolverlo usando el nombre del certificado igual que el FQDN del servidor.

Lo ideal es que la parte SSL se administre en el servidor. El cliente no necesita instalar ningún certificado para SSL. Además, algunas de las publicaciones mencionadas sobre eludir el SSL del código del cliente. Pero estoy totalmente en desacuerdo con eso.

Answer 13

Una solución de una línea. Agregue esto a cualquier lugar antes de llamar al servidor en el lado del cliente:

System.Net.ServicePointManager.ServerCertificateValidationCallback += delegate { return true; };

Esto solo se debe utilizar con fines de prueba porque el cliente omitirá las comprobaciones de seguridad de SSL / TLS.

Answer 14

Yo tuve el mismo problema. También había agregado certificados de CA en la tienda local, pero lo hice de la manera INCORRECTA.

Con la consola mmc (Inicio -> Ejecutar -> mmc ) debe agregar el complemento Certificados como cuenta de servicio (eligiendo la cuenta de servicio de IIS) o cuenta de equipo (se agrega para cada cuenta en la máquina)

Aquí una imagen de lo que estoy hablando

A partir de ahora, puede agregar certificados de CA ( CA de raíz de confianza y CA intermedias ), y todo funcionará bien

Answer 15

los primeros dos usan lambda, el tercero usa código regular ... espero que lo encuentres ú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 = false;
if (cert.Subject.ToUpper().Contains("YourServerName"))
{
result = true;
}
return result;
}