Comment résoudre "Impossible d'établir une relation de confiance pour le canal sécurisé SSL / TLS avec autorité"
Je pensais vraiment avoir résolu ce problème, mais il n’était auparavant que déguisé.
J'ai un service WCF hébergé dans IIS 7 à l'aide de HTTPS. Lorsque je navigue sur ce site dans Internet Explorer, cela fonctionne comme un charme, car j have a ajouté le certificat au magasin d'autorité de certification racine local.
Je développe sur 1 machine, donc le client et le serveur sont la même machine. Le certificat est auto-signé directement à partir de IIS 7 composant logiciel enfichable de gestion.
Je reçois continuellement cette erreur maintenant ...
Impossible d'établir une relation de confiance avec le canal sécurisé SSL/TLS.
... lorsqu'il est appelé depuis la console client.
Je me suis attribué manuellement les autorisations et le service réseau au certificat, en utilisant findprivatekey et en utilisant cacls.exe.
J'ai essayé de me connecter au service à l'aide de SOAPUI, et cela fonctionne. Il doit donc s'agir d'un problème dans mon application client, qui est un code basé sur ce qui fonctionnait avec http.
Où puis-je regarder, je semble avoir épuisé toutes les possibilités pour lesquelles je ne peux pas me connecter?
En guise de solution de contournement, vous pouvez ajouter un gestionnaire au ServicePointManager de ServerCertificateValidationCallback du côté client:
System.Net.ServicePointManager.ServerCertificateValidationCallback +=
(se, cert, chain, sslerror) =>
{
return true;
};
mais sachez que ceci n'est pas une bonne pratique car il ignore complètement le certificat du serveur et indique au gestionnaire de points de service que le certificat est correct, ce qui peut sérieusement compromettre la sécurité du client. Vous pouvez affiner ceci et faire une vérification personnalisée (pour le nom du certificat, le hachage, etc.). au moins, vous pouvez contourner les problèmes lors du développement en utilisant des certificats de test.
Quand j'ai ce problème, c'est parce que le client.config avait ses points finaux comme:
https://myserver/myservice.svc
mais le certificat attendait
https://myserver.mydomain.com/myservice.svc
Changer les systèmes d'extrémité pour qu'ils correspondent au nom de domaine complet du serveur résout mon problème. Je sais que ce n'est pas la seule cause de ce problème.
les deux premiers utilisent lambda, le troisième utilise du code normal ... j'espère que vous le trouverez utile
//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;
}
Votre problème se pose parce que vous utilisez une clé auto-signée. Le client ne fait pas confiance à cette clé et ne fournit pas non plus une chaîne de validation ou une liste de révocation de certificats.
Vous avez quelques options - vous pouvez
désactiver la validation du certificat sur le client (mauvais mouvement, les attaques de type intermédiaire abondent)
utilisez makecert pour créer une autorité de certification racine et créer des certificats à partir de celle-ci (mouvement correct, mais il n'y a toujours pas de liste de révocation de certificats)
créer une autorité de certification racine interne à l'aide de Windows Certificate Server ou d'une autre solution PKI, puis faire confiance à ce certificat racine (difficile à gérer)
acheter un certificat SSL auprès de l'une des autorités de certification approuvées (cher)
Une solution en une seule ligne. Ajoutez ceci n'importe où avant d'appeler le serveur côté client:
System.Net.ServicePointManager.ServerCertificateValidationCallback += delegate { return true; };
Cela ne devrait être utilisé qu'à des fins de test car le client ignorera les contrôles de sécurité SSL/TLS.
J'ai rencontré le même problème et j'ai pu le résoudre avec deux solutions: tout d'abord, j'ai utilisé le composant logiciel enfichable MMC "Certificats" pour le "compte d'ordinateur" et j'ai fait glisser le certificat auto-signé dans le " Autorités de certification racines de confiance ". Cela signifie que l'ordinateur local (celui qui a généré le certificat) va maintenant faire confiance à ce certificat. Deuxièmement, j'ai remarqué que le certificat avait été généré pour un nom d'ordinateur interne, mais que le service Web était utilisé sous un autre nom. Cela a entraîné une incompatibilité lors de la validation du certificat. Nous avons généré le certificat pour computer.operations.local, mais avons accédé au service Web à l'aide de https://computer.internaldomain.companydomain.com . Lorsque nous avons basculé l'URL sur celle utilisée pour générer le certificat, nous n'avons plus d'erreur.
Le simple fait de changer d'URL aurait peut-être fonctionné, mais en faisant en sorte que le certificat soit approuvé, vous évitez également l'écran rouge d'Internet Explorer, qui indique qu'il n'approuve pas le certificat.
Veuillez suivre les étapes suivantes:
Lien de service ouvert dans IE.
Cliquez sur la mention d'erreur de certificat dans la barre d'adresse et cliquez sur Afficher les certificats.
Chèque à l'ordre de: nom.
Prenez le nom émis et remplacez la mention localhost dans le nom de l'adresse de base du service et du client par un nom de domaine complet (FQDN).
Par exemple: https: // localhost: 203/SampleService.svc À https: // INL-126166-.groupinfra.com: 203/SampleService.svc
Si vous utilisez un noyau .net, essayez ceci:
client.ClientCredentials.ServiceCertificate.SslCertificateAuthentication =
new X509ServiceCertificateAuthentication()
{
CertificateValidationMode = X509CertificateValidationMode.None,
RevocationMode = System.Security.Cryptography.X509Certificates.X509RevocationMode.NoCheck
};
Outre les réponses ci-dessus, vous pouvez rencontrer cette erreur si votre client exécute la mauvaise version de TLS, par exemple si le serveur exécute uniquement TLS 1.2.
Vous pouvez le réparer en utilisant:
// tested in .NET 4.5:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
J'ai eu le même problème. J'avais également ajouté des certificats de CA dans le magasin local, mais de la manière FAUX.
À l'aide de la console mmc (Démarrer -> Exécuter -> mmc), vous devez ajouter le composant logiciel enfichable Certificats en tant que compte de service (en choisissant le compte de service d'IIS) ou un compte d'ordinateur (il ajoute pour chaque compte sur la machine)
Voici une image de ce dont je parle 
À partir de maintenant, vous pouvez ajouter des certificats d'AC (AC approuvées et AC intermédiaires), et tout fonctionnera correctement.
J'ai eu le même problème avec le certificat auto-signé. Je pourrais le résoudre en utilisant le même nom de certificat que le nom de domaine complet du serveur.
Idéalement, la partie SSL devrait être gérée côté serveur. Le client n’est pas obligé d’installer un certificat pour SSL. En outre, certains des articles mentionnés sur le contournement de SSL à partir du code client. Mais je suis totalement en désaccord avec cela.
Je viens de faire glisser le certificat dans le dossier "Autorités de certification racines de confiance" et tout est parfait.
Oh. Et j'ai d'abord ajouté ce qui suit à partir d'une invite de commande de l'administrateur:
netsh http add urlacl url=https://+:8732/Servicename user=NT-MYNDIGHET\INTERAKTIV
Je ne suis pas sûr du nom dont vous avez besoin pour l'utilisateur (le mien est norvégien comme vous pouvez le voir!): user=NT-AUTHORITY/INTERACTIVE?
Vous pouvez voir toutes les URL existantes en lançant la commande: netsh http show urlacl
Je viens de corriger un problème similaire.
J'ai réalisé que le pool d'applications qui s'exécutait sous un compte disposant uniquement d'une autorisation de lecture sur le certificat utilisé.
L'application .NET pouvait récupérer correctement le certificat, mais cette exception n'a été levée que lors de l'appel de GetRequestStream ().
Les autorisations de certificats peuvent être gérées via console MMC
Cela s'est produit lors de la tentative de connexion au service WCF en utilisant uniquement le nom d'hôte, par exemple. https: //Host/MyService.svc lors de l'utilisation d'un certificat lié à un nom, par exemple. Host.mysite.com.
Basculer vers le https://Host.mysite.com/MyService.svc et cela a résolu le problème.
Cela s'est produit lors de la tentative de connexion au service WCF via. l'IP par exemple https://111.11.111.1:port/MyService.svc lors de l'utilisation d'un certificat lié à un nom, par exemple. mysite.com.
Le passage à https://mysite.com:port/MyService.svc le résolut.