Comment résoudre "impossible d'établir une relation de confiance pour le canal sécurisé SSL/TLS avec autorité"

Quand j'ai ce problème, c'est parce que le client.config avait ses points de terminaison comme:

 https://myserver/myservice.svc 

Mais le certificat attendait

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

Changer les points de terminaison pour correspondre 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.

Votre problème se pose parce que vous utilisez une clé Auto-signée. Le client ne fait pas confiance à cette clé, pas plus que la clé elle-même ne fournit une chaîne à valider ou une liste de révocation de certificat.

Vous avez quelques options - vous pouvez

1. Désactiver la validation du certificat le client (mauvais mouvement, homme dans le les attaques du milieu abondent)

2. Utilisez makecert pour créer une autorité de certification racine et créez des certificats à partir de cela (ok déplacer, mais il n'y a toujours pas de CRL)

3. Créer une autorité de certification racine interne utilisant Serveur de certificat Windows ou autre Solution PKI puis faire confiance à cette racine cert (un peu de douleur à gérer)

4. Achetez un certificat SSL auprès d'un des CAs de confiance (cher)

Les deux premiers utilisent lambda, le troisième utilise du code régulier... 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;
    }

Une solution d'une ligne. Ajoutez ceci n'importe où avant d'appeler le serveur du côté client:

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

Ceci ne doit ê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 traîné le certificat auto-signé dans le dossier "Autorités de Certification racine 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 a été généré pour un nom d'ordinateur interne, mais que le service web était accessible en utilisant un autre nom. Cela a provoqué une discordance lors de la validation du certificat. Nous avons généré le certificat pour l'ordinateur.opérations.local, mais a accédé au service web en utilisant https://computer.internaldomain.companydomain.com . Lorsque nous avons changé L'URL à celle utilisée pour générer le certificat, nous n'avons plus d'erreurs.

Peut-être que le simple fait de changer D'URL aurait fonctionné, mais en faisant confiance au certificat, vous évitez également l'écran rouge dans Internet Explorer où il vous dit qu'il ne fait pas confiance certificat.

Veuillez suivre les étapes suivantes:

1. Ouvrir le lien de service dans IE.

2. Cliquez sur le certificat d'erreur de mentionner dans la barre d'adresse et cliquez sur Afficher les certificats.

3. Chèque délivré à: nom.

4. Prenez le nom émis et remplacez la mention localhost dans le nom d'adresse de base du service et du client par un nom de domaine complet (FQDN).

Par Exemple: https://localhost:203/SampleService.svc De https: / / INL-126166-.groupinfra.com : 203 / SampleService. svc

J'ai eu le même problème. J'avais également ajouté des certificats de CA dans le magasin local, mais je l'ai fait de la mauvaise façon.

En utilisant la Console mmc (Démarrer - > Exécuter - > mmc ), vous devez ajouter Certificats composant logiciel enfichable en tant que compte de Service (en choisissant le compte de service D'IIS) ou 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 de CAs ( Cas racine de confiance et Cas intermédiaire ), et tout fonctionnera bien

J'ai eu un problème similaire avec le certificat auto-signé. Je pourrais le résoudre en utilisant le nom de certificat identique au nom de domaine complet du serveur.

Idéalement, la partie SSL doit être gérée côté serveur. Le Client n'est pas requis pour installer un certificat pour SSL. En outre, certains des messages mentionnés sur le contournement du SSL à partir du code client. Mais je suis totalement en désaccord avec cela.

Je viens de glisser le certificat dans le dossier "Trusted Root Certification Authorities" et voila tout a bien fonctionné.

Oh. Et j'ai d'abord ajouté ce qui suit à partir d'une invite de commande 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 urlacl existantes en émettant la commande: netsh http show urlacl

En plus des réponses ci-dessus, vous pouvez rencontrer cette erreur si votre client exécute la mauvaise version TLS, par exemple si le serveur exécute uniquement TLS 1.2.

Vous pouvez le réparer en utilisant:

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

Cela s'est produit lorsque vous essayez de vous connecter 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.

Passage à la https://host.mysite.com/MyService.svc {[2] } et cela l'a résolu.

Cela s'est produit lorsque vous essayez de vous connecter au Service WCF via. l'adresse 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 au https://mysite.com:port/MyService.svc l'a résolu.

Juste corrigé un problème similaire.

J'ai réalisé que j'avais un pool d'applications qui s'exécutait sous un compte qui n'avait que l'autorisation de lecture sur le certificat qu'il était utilisé.

L'application. Net a pu récupérer correctement le certificat, mais cette exception n'a été levée que lorsque GetRequestStream () a été appelée.

Les autorisations de certificats peuvent être gérées via la console MMC

Ajoutez ceci à votre code client:

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