Impossible d'établir une relation de confiance pour le canal sécurisé SSL/TLS - SOAP

Question

J'ai un appel de service web simple, généré par une application Windows .NET (C#) 2.0, via le proxy de service web généré par Visual Studio, pour un service web également écrit en C# (2.0). Cela a fonctionné pendant plusieurs années et continue de le faire dans une douzaine d'endroits où il est exécuté.

Une nouvelle installation sur un nouveau site rencontre un problème. Lors de la tentative d'invocation du service web, cela échoue avec le message suivant :

Impossible d'établir une relation de confiance pour le canal sécurisé SSL/TLS

L'URL du service web utilise SSL (https://) -- mais cela fonctionne depuis longtemps (et continue de le faire) depuis de nombreux autres endroits.

Où dois-je regarder? Est-ce un problème de sécurité entre Windows et .NET qui est propre à cette installation? Si c'est le cas, où puis-je configurer les relations de confiance? Je suis perdu!

Answer 1

Les extraits suivants corrigeront le cas où il y a un problème avec le certificat SSL sur le serveur que vous appelez. Par exemple, il peut être auto-signé ou le nom d'hôte entre le certificat et le serveur peut ne pas correspondre.

C'est dangereux si vous appelez un serveur en dehors de votre contrôle direct, car vous ne pouvez plus être sûr que vous parlez au serveur auquel vous pensez être connecté. Cependant, si vous traitez avec des serveurs internes et obtenir un certificat "correct" n'est pas pratique, utilisez ce qui suit pour dire au service web d'ignorer les problèmes de certificat et de continuer courageusement.

Les deux premiers utilisent des expressions lambda, le troisième utilise du code régulier. Le premier accepte n'importe quel certificat. Les deux derniers vérifient au moins que le nom d'hôte dans le certificat est celui auquel vous vous attendez.
... j'espère que vous trouverez cela utile

//Faites confiance à tous les certificats
System.Net.ServicePointManager.ServerCertificateValidationCallback =
    ((sender, certificate, chain, sslPolicyErrors) => true);

// faites confiance à l'expéditeur
System.Net.ServicePointManager.ServerCertificateValidationCallback
                = ((sender, cert, chain, errors) => cert.Subject.Contains("NomDeVotreServeur"));

// valider le certificat en appelant une fonction
ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(ValiderCertificatDistant);

// rappel utilisé pour valider le certificat lors d'une conversation SSL
private static bool ValiderCertificatDistant(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors policyErrors)
{
    bool result = cert.Subject.Contains("NomDeVotreServeur");
    return result;
}

Answer 2

La solution très simple "catch all" est la suivante :

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

La solution de sebastian-castaldi est un peu plus détaillée.

Answer 3

Pensées (basées sur la douleur du passé) :

• avez-vous le DNS et la ligne de mire sur le serveur ?
• utilisez-vous le nom correct du certificat ?
• le certificat est-il toujours valide ?
• un équilibreur de charge mal configuré perturbe-t-il les choses ?
• la nouvelle machine a-t-elle l'horloge correctement réglée (c'est-à-dire que l'heure UTC est correcte [ignorez l'heure locale, elle est largement sans importance]) - cela compte certainement pour WCF, donc cela pourrait avoir un impact sur le SOAP régulier ?
• y a-t-il un problème de chaîne de confiance de certificat ? si vous naviguez du serveur vers le service SOAP, pouvez-vous obtenir SSL ?
• en lien avec ce qui précède - le certificat a-t-il été installé au bon emplacement ? (vous pouvez avoir besoin d'une copie dans Autorités de certification racine de confiance)
• le proxy au niveau de la machine du serveur est-il correctement configuré ? (différent du proxy de l'utilisateur) ; voir proxycfg pour XP / 2003 (pas sûr pour Vista, etc.)

Answer 4

Je préfère personnellement la solution suivante :

using System.Security.Cryptography.X509Certificates;
using System.Net.Security;

... puis avant de faire la demande et d'obtenir l'erreur, faites ce qui suit

System.Net.ServicePointManager.ServerCertificateValidationCallback = delegate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors) { return true; };

Je l'ai trouvé après avoir consulté la solution de Luke

Answer 5

Si vous utilisez Windows 2003, vous pouvez essayer ceci:

Ouvrez la Console de gestion Microsoft (Démarrer --> Exécuter --> mmc.exe);

Choisissez Fichier --> Ajouter/Supprimer un composant logiciel enfichable;

Dans l'onglet Standalone, choisissez Ajouter;

Choisissez le composant logiciel enfichable Certificats, et cliquez sur Ajouter;

Dans l'assistant, choisissez le Compte d'ordinateur, puis choisissez Ordinateur local. Appuyez sur Terminer pour terminer l'assistant;

Fermez la boîte de dialogue Ajouter/Supprimer un composant logiciel enfichable;

Naviguez vers Certificats (Ordinateur local) et choisissez un magasin à importer:

Si vous avez le certificat AC racine de l'entreprise qui a émis le certificat, choisissez Autorités de certification racine de confiance;

Si vous avez le certificat du serveur lui-même, choisissez Autres personnes

Cliquez avec le bouton droit sur le magasin et choisissez Toutes les tâches --> Importer

Suivez l'assistant et fournissez le fichier de certificat que vous avez;

Après cela, redémarrez simplement IIS et essayez d'appeler à nouveau le service web.

Référence: http://www.outsystems.com/NetworkForums/ViewTopic.aspx?Topic=Web-Services:-Could-not-establish-trust-relationship-for-the-SSL/TLS-...