La demande a été abandonnée: impossible de créer un canal sécurisé SSL / TLS

J’ai finalement 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 append ceci au début:

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

Et maintenant, cela fonctionne parfaitement.

ADDENDA

Comme mentionné par Robin French; PayPal ne supporte plus SSL3, vous devrez donc utiliser TLS1.2. Page d’information Paypal

La solution à cela, dans .NET 4.5 est

 ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; 

Si vous n’avez pas de .NET 4.5, utilisez

 ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072; 

Le problème que vous rencontrez est que l’utilisateur aspNet n’a pas access au certificate. Vous devez donner access à l’aide de winhttpcertcfg.exe

Un exemple sur la façon de configurer ceci est à: http://support.microsoft.com/kb/901183

Sous l’étape 2 de plus d’informations

EDIT: dans les versions plus récentes d’IIS, cette fonctionnalité est intégrée à l’outil du gestionnaire de certificates – accessible en cliquant avec le bouton droit sur le certificate 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-certificatee-in-certificatee-store/132791#132791

L’erreur est générique et il existe de nombreuses raisons pour lesquelles la négociation SSL / TLS peut échouer. Le plus courant est un certificate de serveur non valide ou expiré, et vous vous en êtes occupé en fournissant votre propre hook de validation de certificate de serveur, mais ce n’est pas nécessairement la seule raison. Le serveur peut nécessiter une authentification mutuelle, il peut être configuré avec une suite de chiffrements non pris en charge par votre client, il peut avoir une dérive de temps trop importante pour que la poignée de main réussisse et bien d’autres raisons.

La meilleure solution consiste à utiliser les outils de dépannage SChannel. SChannel est le fournisseur SSPI responsable de SSL et de TLS et votre client l’utilisera pour la prise de contact. Jetez un coup d’œil aux outils et parameters TLS / SSL .

Voir également Comment activer la journalisation des événements Schannel .

J’ai eu ce problème en essayant de bash https://ct.mob0.com/Styles/Fun.png , qui est une image dissortingbuée par CloudFlare sur son CDN qui supporte des choses folles comme SPDY et des certificates SSL de redirection bizarres.

Au lieu de spécifier Ssl3 comme dans la réponse de Simons, j’ai pu résoudre ce problème en allant dans Tls12 comme ceci:

 ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png"); 

Quelque chose que la réponse originale n’avait pas. J’ai ajouté un peu de code pour en faire une preuve de balle.

 ServicePointManager.Expect100Continue = true; ServicePointManager.DefaultConnectionLimit = 9999; ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3; 

Une autre possibilité est l’importation incorrecte de certificates sur la boîte. Veillez à sélectionner une case à cocher entourée. Au début, je ne l’avais pas fait, donc le code était soit en expiration, soit en générant la même exception que la clé privée ne pouvait pas être localisée.

Après de longues heures avec ce même problème, j’ai constaté que le compte ASP.NET sous lequel le service client était exécuté n’avait pas access au certificate. Je l’ai corrigé en allant dans le pool d’applications IIS sous lequel l’application Web s’exécute, en allant dans Paramètres avancés et en changeant l’identité du compte LocalSystem partir de NetworkService .

Une meilleure solution consiste à faire en sorte que le certificate fonctionne avec le compte NetworkService par défaut, mais cela fonctionne pour des tests fonctionnels rapides.

Celui-ci travaille pour moi dans MVC webclient

  public ssortingng DownloadSite(ssortingng RefinedLink) { try { Uri address = new Uri(RefinedLink); ServicePointManager.ServerCertificateValidationCallback = delegate { return true; }; ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3; System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12; using (WebClient webClient = new WebClient()) { var stream = webClient.OpenRead(address); using (StreamReader sr = new StreamReader(stream)) { var page = sr.ReadToEnd(); return page; } } } catch (Exception e) { log.Error("DownloadSite - error Lin = " + RefinedLink, e); return null; } } 

Comme vous pouvez le constater, les raisons sont nombreuses. Je pensais que j’appendais la cause que j’ai rencontrée …

Si vous définissez la valeur de WebRequest.Timeout sur 0 , il s’agit de l’exception qui est lancée. Voici le code que j’avais … (Sauf au lieu d’un 0 codé en dur pour la valeur du délai d’attente, j’avais un paramètre qui était par inadvertance défini sur 0 ).

 WebRequest webRequest = WebRequest.Create(@"https://myservice/path"); webRequest.ContentType = "text/html"; webRequest.Method = "POST"; ssortingng 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 ... 

L’exception “La requête a été abandonnée: impossible de créer un canal sécurisé SSL / TLS” peut survenir si le serveur renvoie une réponse HTTP 401 non autorisée à la requête HTTP.

Vous pouvez déterminer si cela se produit en activant la journalisation System.Net au niveau de la trace pour votre application client, comme décrit dans cette réponse .

Une fois la configuration de la journalisation en place, exécutez l’application et reproduisez l’erreur, puis recherchez dans la sortie de journalisation une ligne comme celle-ci:

 System.Net Information: 0 : [9840] Connection#62912200 - Received status line: Version=1.1, StatusCode=401, StatusDescription=Unauthorized. 

Dans ma situation, je n’arrivais pas à définir un cookie particulier attendu par le serveur, ce qui conduisait le serveur à répondre à la requête avec l’erreur 401, ce qui conduisait à l’exception “Impossible de créer un canal sécurisé SSL / TLS”.

Assurez-vous que les parameters de ServicePointManager sont définis avant la création de HttpWebRequest, sinon cela ne fonctionnera pas.

Travaux:

  ServicePointManager.Expect100Continue = true; ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3; HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/") 

Échoue:

  HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/") ServicePointManager.Expect100Continue = true; ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3; 

J’ai lutté avec ce problème toute la journée.

Lorsque j’ai créé un nouveau projet avec .NET 4.5, j’ai enfin réussi à le faire fonctionner.

Mais si je suis passé à la version 4.0, j’ai eu le même problème, et il était irréversible pour ce projet (même lorsque j’ai essayé de passer à nouveau à la version 4.5).

Étrange Pas d’autre message d’erreur mais “La demande a été abandonnée: impossible de créer un canal sécurisé SSL / TLS.” est venu pour cette erreur

La racine de cette exception dans mon cas était qu’à un moment donné dans le code on appelait ce qui suit:

 ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3; 

C’est vraiment mauvais. Non seulement il demande à .NET d’utiliser un protocole non sécurisé, mais cela affecte toutes les nouvelles requêtes WebClient (et similaires) effectuées ultérieurement dans votre domaine d’application. (Notez que les demandes Web entrantes ne sont pas affectées par votre application ASP.NET, mais que les nouvelles requêtes WebClient, telles que la communication avec un service Web externe, sont).

Dans mon cas, ce n’était pas vraiment nécessaire, donc je pouvais simplement supprimer la déclaration et toutes mes autres requêtes Web ont recommencé à fonctionner. Sur la base de mes lectures ailleurs, j’ai appris quelques choses:

• Il s’agit d’un paramètre global dans votre domaine d’application. Si vous avez des activités simultanées, vous ne pouvez pas définir de manière fiable une valeur, effectuer votre action et la rétablir. Une autre action peut avoir lieu pendant cette petite fenêtre et être impactée.
• Le paramètre correct est de laisser la valeur par défaut. Cela permet à .NET de continuer à utiliser la valeur par défaut la plus sécurisée au fil du temps et de mettre à niveau les frameworks. Le paramétrer sur TLS12 (qui est le plus sécurisé à ce jour) fonctionnera maintenant, mais dans 5 ans, des problèmes mystérieux pourraient apparaître.
• Si vous avez vraiment besoin de définir une valeur, vous devriez envisager de le faire dans une application ou un domaine d’application spécifique et de trouver un moyen de discuter avec votre pool principal. Comme il s’agit d’une valeur globale unique, essayer de la gérer dans un pool d’applications surchargé ne peut que générer des problèmes. Cette réponse: https://stackoverflow.com/a/26754917/7656 fournit une solution possible au moyen d’un proxy personnalisé. (Remarque je ne l’ai pas personnellement implémenté.)

Une autre cause possible de The request was aborted: Could not create SSL/TLS secure channel erreur de The request was aborted: Could not create SSL/TLS secure channel est une incompatibilité entre les valeurs de cipher_suites configurées sur votre PC client et les valeurs que le serveur est configuré comme pouvant accepter . Dans ce cas, lorsque votre client envoie la liste des valeurs de cipher_suites qu’il est capable d’accepter dans son message de négociation / négociation client “Client Hello” initial, le serveur voit qu’aucune des valeurs fournies n’est acceptable et peut renvoyer une “alerte”. “réponse au lieu de procéder à l’étape” Server Hello “de la négociation SSL.

Pour étudier cette possibilité, vous pouvez télécharger Microsoft Message Analyzer et l’utiliser pour exécuter une trace de la négociation SSL qui se produit lorsque vous essayez d’établir une connexion HTTPS au serveur (dans votre application C #).

Si vous parvenez à établir une connexion HTTPS à partir d’un autre environnement (par exemple, la machine Windows XP que vous avez mentionnée ou éventuellement en touchant l’URL HTTPS dans un navigateur non Microsoft n’utilisant pas les parameters de la suite de chiffrement du système d’exploitation) Chrome ou Firefox), exécutez une autre trace Message Analyzer dans cet environnement pour capturer ce qui se passe lorsque la négociation SSL aboutit.

J’espère que vous verrez une différence entre les deux messages Client Hello, ce qui vous permettra de cerner exactement la défaillance de la négociation SSL. Ensuite, vous devriez pouvoir apporter des modifications à la configuration de Windows qui lui permettront de réussir. IISCrypto est un excellent outil à utiliser pour cela (même pour les PC clients, malgré le nom “IIS”).

Les deux clés de registre Windows suivantes régissent les valeurs de cipher_suites que votre PC utilisera:

• HKLM \ SOFTWARE \ Policies \ Microsoft \ Cryptography \ Configuration \ SSL \ 00010002
• HKLM \ SYSTEM \ CurrentControlSet \ Control \ Cryptographie \ Configuration \ Local \ SSL \ 00010002

Voici une description complète de la manière dont j’ai étudié et résolu une instance de cette variété du problème du Could not create SSL/TLS secure channel : http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in -windows.html

Dans le cas où le client est une machine Windows, une raison possible pourrait être que le protocole tls ou ssl requirejs par le service n’est pas activé.

Cela peut être défini dans:

Panneau de configuration -> Réseau et Internet -> Options Internet -> Avancé

Faites défiler les parameters jusqu’à “Sécurité” et choisissez entre

• Utilisez SSL 2.0
• Utilisez SSL 3.0
• Utilisez TLS 1.0
• Utilisez TLS 1.1
• Utilisez TLS 1.2

J’ai eu ce problème parce que mon web.config avait:

et pas:

Dans mon cas, le compte de service exécutant l’application n’était pas autorisé à accéder à la clé privée. Une fois que j’ai donné cette permission, l’erreur a disparu

1. mmc
2. certificates
3. Développez pour personnel
4. sélectionnez cert
5. clic-droit
6. Toutes les tâches
7. Gérer les clés privées
8. Ajouter

Si vous exécutez votre code à partir de Visual Studio, essayez d’exécuter Visual Studio en tant qu’administrateur. Correction du problème pour moi

J’avais ce même problème et j’ai trouvé que cette réponse fonctionnait correctement pour moi. La clé est 3072. Ce lien fournit les détails sur le correctif ‘3072’.

 ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072; XmlReader r = XmlReader.Create(url); SyndicationFeed albums = SyndicationFeed.Load(r); 

Dans mon cas, deux stream nécessitaient le correctif:

 https://www.fbi.gov/feeds/fbi-in-the-news/atom.xml https://www.wired.com/feed/category/gear/latest/rss 

System.Net.WebException: La requête a été abandonnée: impossible de créer un canal sécurisé SSL / TLS.

Dans notre cas, nous utilisions un éditeur de logiciel pour que nous n’ayons pas access au code .NET. Apparemment, .NET 4 n’utilisera pas TLS v 1.2 sauf en cas de changement.

Le correctif pour nous était d’append la clé SchUseStrongCrypto au registre. Vous pouvez copier / coller le code ci-dessous dans un fichier texte avec l’extension .reg et l’exécuter. Il a servi de “patch” au problème.

 Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319] "SchUseStrongCrypto"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SchUseStrongCrypto"=dword:00000001 

Vous pouvez essayer d’installer un certificate de démonstration (certains fournisseurs de services SSL les offrent gratuitement pendant un mois) pour vous assurer que le problème est lié à la validité de votre certificate.

Tant que c’est un lien “live”, j’ai pensé append une nouvelle option. Cette possibilité est que le service ne supporte plus SSL 3.0 en raison du problème de l’attaque Poodle. Consultez la déclaration de Google à ce sujet. J’ai rencontré ce problème avec plusieurs services Web à la fois et réalisé que quelque chose devait se passer. Je suis passé à TLS 1.2 et tout fonctionne à nouveau.

http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

Le problème pour moi était que j’essayais de déployer sur IIS en tant que service Web, j’ai installé le certificate sur le serveur, mais l’utilisateur qui exécute IIS ne disposait pas des permissions appropriées sur le certificate.

Comment accorder l’access ASP.NET à une clé privée dans un certificate du magasin de certificates?

Cela se passait pour moi sur un seul site et il s’est avéré que seul le chiffrement RC4 était disponible. Dans un effort préalable pour durcir le serveur, j’avais désactivé le chiffrement RC4, une fois réactivé, le problème était résolu.

En plus des réponses ci-dessus, assurez-vous d’avoir importé le certificate CER et NON le fichier PFX dans votre magasin de machines local. Une erreur courante lorsque vous avez les deux fichiers.

Dans mon cas, j’ai eu ce problème lorsqu’un service Windows a essayé de se connecter à un service Web. En regardant dans les événements Windows, j’ai finalement trouvé un code d’erreur.

L’ID d’événement 36888 (Schannel) est déclenché:

 The following fatal alert was generated: 40. The internal error state is 808. 

Enfin, il était lié à un correctif Windows. Dans mon cas: KB3172605 et KB3177186

La solution proposée dans le forum vmware consistait à append une entrée de registre dans Windows. Après avoir ajouté le registre suivant, tout fonctionne bien.

[HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ KeyExchangeAlgorithms \ Diffie-Hellman]

“ClientMinKeyBitLength” = dword: 00000200

Apparemment, il est lié à une valeur manquante dans la poignée de main https du côté client.

Listez votre Windows HotFix:

 wmic qfe list 

Fil de solution:

https://communities.vmware.com/message/2604912#2604912

J’espère que ça aide.

Le ServicePointManager.SecurityProtocol .NET ServicePointManager.SecurityProtocol par défaut utilise SSLv3 et TLS. Si vous accédez à un serveur Apache, il existe une variable de configuration appelée SSLProtocol qui SSLProtocol défaut TLSv1.2. Vous pouvez définir ServicePointManager.SecurityProtocol pour qu’il utilise le protocole approprié pris en charge par votre serveur Web ou modifier votre configuration Apache pour autoriser tous les protocoles tels que ce protocole SSLProtocol .

Cela corrigé pour moi, ajoutez le service réseau aux permissions. Clic droit sur le certificate> Toutes les tâches> Gérer les clés privées> Ajouter> Service réseau

J’ai rencontré le même problème récemment. Mon environnement s’exécute sous .NET 4.6.1 avec VB.NET. C’est comme ça que j’ai résolu le problème:

 ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 ServicePointManager.ServerCertificateValidationCallback = New RemoteCertificateValidationCallback(AddressOf util.ValidateServerCertificate) 

et la fonction util.ValidateServerCertificate est:

 Public Function ValidateServerCertificate(ByVal sender As Object, ByVal certificatee As X509Certificate, ByVal chain As X509Chain, ByVal sslPolicyErrors As SslPolicyErrors) As Boolean Return True End Function