La demande a été interrompue : Impossible de créer un canal sécurisé SSL/TLS

Question

Nous n'arrivons pas à nous connecter à un serveur HTTPS en utilisant WebRequest à cause de ce message d'erreur :

The request was aborted: Could not create SSL/TLS secure channel.

Nous savons que le serveur n'a pas de certificat HTTPS valide avec le chemin utilisé, mais pour contourner ce problème, nous utilisons le code suivant que nous avons pris d'un autre post StackOverflow :

private void Somewhere() {
    ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(AlwaysGoodCertificate);
}

private static bool AlwaysGoodCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors) {
   return true;
}

Le problème est que le serveur ne valide jamais le certificat et échoue avec l'erreur ci-dessus. Quelqu'un a-t-il une idée de ce que je dois faire ?

---

Je dois mentionner qu'un collègue et moi avons effectué des tests il y a quelques semaines et que cela fonctionnait bien avec quelque chose de similaire à ce que j'ai écrit ci-dessus. La seule "différence majeure" que nous avons trouvée est que j'utilise Windows 7 et qu'il utilisait Windows XP. Cela change-t-il quelque chose ?

Answer 1

J'ai enfin trouvé la réponse (je n'ai pas noté ma source mais c'était à partir d'une recherche) ;

Alors que le code fonctionne sous Windows XP, sous Windows 7, vous devez ajouter ceci au début :

// using System.Net;
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
// Use SecurityProtocolType.Ssl3 if needed for compatibility reasons

Et maintenant, ça fonctionne parfaitement.

---

ADDENDUM

Comme mentionné par Robin French ; si vous rencontrez ce problème lors de la configuration de PayPal, veuillez noter qu'ils ne supporteront pas SSL3 à partir du 3 décembre 2018. Vous devrez utiliser TLS. Voici Page Paypal à ce sujet.

Answer 2

Le problème que vous rencontrez est que l'utilisateur aspNet n'a pas accès au certificat. Vous devez lui donner accès en utilisant le fichier winhttpcertcfg.exe.

Vous trouverez un exemple de la façon de procéder à l'adresse suivante : http://support.microsoft.com/kb/901183

Sous l'étape 2 en plus d'informations

EDIT : Dans les versions plus récentes d'IIS, cette fonction est intégrée à l'outil de gestion des certificats - et est accessible en faisant un clic droit sur le certificat et en utilisant l'option de gestion des clés privées. Plus de détails ici : https://serverfault.com/questions/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791#132791

Answer 3

L'erreur est générique et il existe de nombreuses raisons pour lesquelles la négociation SSL/TLS peut échouer. La plus courante est un certificat de serveur invalide ou expiré, et vous avez pris soin de cela en fournissant votre propre crochet de validation de certificat de serveur, mais ce n'est pas nécessairement la seule raison. Le serveur peut exiger une authentification mutuelle, il peut être configuré avec une suite de chiffres non supportée par votre client, il peut avoir une dérive temporelle trop importante pour que la poignée de main réussisse et bien d'autres raisons encore.

La meilleure solution consiste à utiliser le jeu d'outils de dépannage SChannel. SChannel est le fournisseur SSPI responsable de SSL et TLS et votre client l'utilisera pour la poignée de main. Jetez un coup d'œil à Outils et paramètres TLS/SSL .

Voir aussi Comment activer la journalisation des événements de Schannel .

Answer 4

Une autre possibilité est l'importation incorrecte du certificat sur la boîte. Veillez à cocher la case encerclée. Initialement, je ne l'ai pas fait, donc le code était soit en train de se bloquer, soit de lancer la même exception que la clé privée ne pouvait pas être localisée.

Answer 5

Comme vous pouvez le constater, il y a de nombreuses raisons pour lesquelles cela peut se produire. J'ai pensé ajouter la cause que j'ai rencontrée ...

Si vous définissez la valeur de WebRequest.Timeout à 0 c'est l'exception qui est levée. Voici le code que j'avais... (sauf qu'au lieu d'un code dur 0 pour la valeur du délai d'attente, j'avais un paramètre qui était par inadvertance réglé sur 0 ).

WebRequest webRequest = WebRequest.Create(@"https://myservice/path");
webRequest.ContentType = "text/html";
webRequest.Method = "POST";
string body = "...";
byte[] bytes = Encoding.ASCII.GetBytes(body);
webRequest.ContentLength = bytes.Length;
var os = webRequest.GetRequestStream();
os.Write(bytes, 0, bytes.Length);
os.Close();
webRequest.Timeout = 0; //setting the timeout to 0 causes the request to fail
WebResponse webResponse = webRequest.GetResponse(); //Exception thrown here ...