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


433

Nous ne pouvons pas nous connecter à un serveur HTTPS à l'aide WebRequestde 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 d'accès utilisé, mais pour contourner ce problème, nous utilisons le code suivant que nous avons extrait d'un autre article 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?



51
Nous sommes en 2018 et cette question a été vue 308 056 fois mais il n'y a toujours pas de solution appropriée pour cela !! J'obtiens ce problème au hasard et aucun des correctifs mentionnés ici ou dans aucun autre thread n'a résolu mon problème.
Nigel Fds

3
@NigelFds L'erreur The request was aborted: Could not create SSL/TLS secure channelest très générique. Il dit essentiellement, "l'initialisation de la connexion SSL / TLS / HTTPS a échoué pour l'une des nombreuses raisons possibles". Donc, si vous l'obtenez régulièrement dans une situation spécifique, votre meilleure option est de poser une question spécifique donnant des détails spécifiques sur cette situation. Et consultez l'Observateur d'événements pour plus d'informations. Et / ou activez un débogage côté client .NET pour obtenir plus de détails (le certificat du serveur n'est-il pas approuvé? Y a-t-il une incompatibilité de chiffrement? Incompatibilité de version du protocole SSL / TLS? Etc.).
MarnixKlooster ReinstateMonica

4
@MarnixKlooster J'ai déjà vérifié tout cela, ça ne peut pas être un problème avec le certificat comme si je le réessayais, ça marche. Et je doute que je serais en mesure de poser cette question sur SO sans que quelqu'un vienne et la marque comme doublon ou quelque chose.
Nigel Fds

1
Je lutte contre ce problème peut-être pour la 4e fois. La même base de code que j'utilise fonctionne bien en production et également dans l'environnement de développement de certains de mes collègues développeurs. La dernière fois, j'ai été invité à ajouter une valeur de Registre Computer \ HKEY_LOCAL_MACHINE \ SOFTWARE \ WOW6432Node \ Microsoft \ .NETFramework \ v4.7.02046 \ SchUseStrongCrypto [DWORD] = 1. Et cela a fonctionné pendant un certain temps. J'ai commencé à travailler dans un autre projet pendant un certain temps et maintenant je suis de retour à ce projet et la demande échoue à nouveau, même avec cette correction de clé de registre. Très ennuyant.
Miguel

Réponses:


599

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 dans Windows XP, dans 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, cela fonctionne parfaitement.


ADDENDA

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


5
Descendre à SecurityProtocolType.Tls12 a en fait résolu ce problème pour moi. Voir ma réponse ci-dessous.
Bryan Legend

24
SSLv3 a 18 ans et est maintenant vulnérable à l'exploit POODLE - car @LoneCoder recommande SecurityProtocolType.Tls12 est le remplacement approprié de SecurityProtocolType.Ssl3
gary

4
SecurityProtocolType.Tls pourrait effectivement être une meilleure alternative jusqu'à ce qu'un exploit est trouvé pour que (tous les sites prennent en charge Tls12 comme de l' écriture)
gary

3
PayPal a fixé une date au 30 juin 2017 pour désactiver SSL3 et implémenter TLS1.2. Il est déjà appliqué dans leur environnement sandbox paypal-knowledge.com/infocenter/…
Robin French

11
Voyez cela aussi. Vous n'avez pas besoin de le définir exclusivement sur un seul type, vous pouvez simplement l'ajouter également. System.Net.ServicePointManager.SecurityProtocol |= System.Net.SecurityProtocolType.Tls12;
Nae

154

La solution à cela, dans .NET 4.5 est

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Si vous n'avez pas .NET 4.5, utilisez

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

10
Je vous remercie! J'ai besoin d'utiliser .net 4.0 et je ne savais pas comment résoudre ce problème. Cela semble fonctionner ici. :)
Fabiano

Ne fonctionne pas sur Windows Server 2008R2 (et peut-être aussi sur 2012)
Misam

@billpg, lisez ceci pour une réponse plus exacte
Vikrant

Pour les types VB (puisque cette réponse apparaît dans Google), le code équivalent estServicePointManager.SecurityProtocol = DirectCast(3072, SecurityProtocolType)
ConfusionTowers

@Andrej Z son travail sur le framework .net 4. Merci.
az fav

108

Assurez-vous que les paramètres 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;

4
Quelle est la différence entre Works et Fails que vous avez mentionnée ci-dessus?
Chandy Kunhu

5
Impressionnant. Ma demande n'a fonctionné qu'après le deuxième essai, ce qui n'avait pas de sens, puis j'ai vu votre message, déplacé le protocole de sécurité avant la demande et voilà, corrigé. Merci @ hogarth45
deanwilliammills

2
Exactement! lorsque j'ai placé ServicePointManager juste avant la création de la demande, cela a fonctionné pour moi, merci mec, vous avez sauvé ma journée.

1
Parfait ... c'est merveilleux
Maryam Bagheri

1
Dans notre cas, la demande a échoué pour la première fois et a fonctionné par la suite. C'était exactement pour la raison indiquée dans cette réponse!
Mohammad Dehghan

34

Le problème que vous rencontrez est que l'utilisateur aspNet n'a pas accès au certificat. Vous devez autoriser l'accès à l'aide de winhttpcertcfg.exe

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

Sous l'étape 2 dans plus d'informations

EDIT: dans les versions plus récentes d'IIS, cette fonctionnalité est intégrée à l'outil de gestion des certificats - et est accessible en cliquant avec le bouton droit sur le certificat et en utilisant l'option de gestion des clés privées. Plus de détails ici: /server/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791#132791


J'ai essayé d'exécuter winhttpcertcfg.exe ... notez que je suis sous Windows 7. Peut-il changer quelque chose?
Simon Dugré

Je ne sais pas si c'est lié, mais ce message m'a donné l'idée d'exécuter VS en tant qu'administrateur lors de cet appel depuis VS et cela a résolu le problème pour moi.
PFranchise

2
Dans Windows 7 et versions ultérieures, le certificat doit être dans le magasin de l'ordinateur local plutôt que de l'utilisateur actuel afin de "Gérer les clés privées"
Lukos

1
Oui, c'était mon problème. utilisez mmc.exe, ajoutez le composant logiciel enfichable certificats (pour moi, j'ai ensuite choisi «ordinateur local»). Cliquez avec le bouton droit sur le certificat, toutes les tâches, gérez les clés privées. Ajoutez 'tout le monde' (pour les développeurs locaux, c'est plus simple - le prod a évidemment besoin de votre pool / utilisateur explicite d'applications IIS)
Ian Yates

@lIan Yates, cette solution n'a fonctionné que pour moi (y)
Usman Younas

31

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 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 nécessiter une authentification mutuelle, il peut être configuré avec une suite de chiffres non pris en charge par votre client, il peut y avoir une dérive de temps trop grande pour que la prise de contact réussisse et bien d'autres raisons.

La meilleure solution consiste à utiliser l'ensemble d'outils de dépannage SChannel. SChannel est le fournisseur SSPI responsable de SSL et TLS et votre client l'utilisera pour la prise de contact. Jetez un œil aux outils et paramètres TLS / SSL .

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


Où est le chemin d' accèsSchannel event logging dans Windows 7-8-10 ?
PreguntonCojoneroCabrón

dépanner TLS / SSL par programme en C #?
Kiquenet

27

J'ai eu ce problème en essayant de frapper https://ct.mob0.com/Styles/Fun.png , qui est une image distribuée par CloudFlare sur son CDN qui prend en charge des trucs fous comme SPDY et des certificats SSL de redirection étrange.

Au lieu de spécifier Ssl3 comme dans la réponse Simons, j'ai pu le réparer en descendant vers Tls12 comme ceci:

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

Merci Lone ... c'est fou comment il semble y avoir beaucoup de possibilités différentes de problèmes selon la situation ... Et, comme je peux le voir, il n'y a pas de véritable documentation à ce sujet. Eh bien, merci de signaler à quelqu'un qui pourrait rencontrer le même problème.
Simon Dugré

Cela a fonctionné pour moi. J'ai rencontré l'erreur lorsque je suis passé du LAN du bureau à mon réseau domestique. Même code, même ordinateur portable!
Amal

Obtenez-vous l'erreur toujours (dans toutes les demandes) ou parfois ?
PreguntonCojoneroCabrón

24

Après de longues heures avec ce même problème, j'ai constaté que le compte ASP.NET sous lequel le service client s'exécutait n'avait pas accès au certificat. Je l'ai corrigé en accédant au pool d'applications IIS sous lequel l'application Web s'exécute, en accédant aux paramètres avancés et en modifiant l'identité du LocalSystemcompte NetworkService.

Une meilleure solution consiste à faire fonctionner le certificat avec le NetworkServicecompte par défaut , mais cela fonctionne pour des tests fonctionnels rapides.


3
Cette réponse devrait avoir plus de votes positifs. Après une semaine de recherches, c'est la seule solution qui a fonctionné pour moi. Merci!!
user224567893

Cela a fonctionné pour moi. parfait merci.
Emy Stats

18

L'approche avec le réglage

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Semble être correct, car Tls1.2 est la dernière version du protocole sécurisé. Mais j'ai décidé de regarder plus en profondeur et de répondre avons-nous vraiment besoin de le coder en dur.

Spécifications: Windows Server 2012R2 x64.

Sur Internet, il est indiqué que .NetFramework 4.6+ doit utiliser Tls1.2 par défaut. Mais quand j'ai mis à jour mon projet en 4.6, rien ne s'est produit. J'ai trouvé des informations qui indiquent que j'ai besoin de faire manuellement quelques modifications pour activer Tls1.2 par défaut

https://support.microsoft.com/en-in/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi

Mais la mise à jour Windows proposée ne fonctionne pas pour la version R2

Mais ce qui m'a aidé, c'est d'ajouter 2 valeurs au registre. Vous pouvez utiliser le prochain script PS pour qu'ils soient ajoutés automatiquement

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

C'est un peu ce que je cherchais. Mais je ne peux toujours pas répondre à la question de savoir pourquoi NetFramework 4.6+ ne définit pas cette valeur de protocole automatiquement?


17

Quelque chose que la réponse originale n'avait pas. J'ai ajouté un peu plus de code pour le rendre à l'épreuve des balles.

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

8
Je ne recommanderais pas le protocole SSL3 ajouté.
Peter de Bruijn

SSL3 a un grave problème de sécurité appelé «Poodle».
Peter de Bruijn

@PeterdeBruijn Tls and Tls11sont obsolètes ?
Kiquenet

1
@Kiquenet - oui. À partir de juin 2018, la PCI (Payment Card Industries) n'autorisera pas les protocoles inférieurs à TLS1.2. (Initialement prévu pour 06/2017 mais reporté d'un an)
GlennG

Il existe cinq protocoles dans la famille SSL / TLS: SSL v2, SSL v3, TLS v1.0, TLS v1.1 et TLS v1.2 : github.com/ssllabs/research/wiki/… SSL v2 unsecure, SSL v3 is insecure when used with HTTP (the POODLE attack), TLS v1.0, TLS v1.1 obsoletes Seule une option valide sera ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12?
Kiquenet

14

Une autre possibilité est l'importation incorrecte de certificats sur la boîte. Assurez-vous de cocher la case encerclée. Initialement, je ne l'ai pas fait, donc le code expirait ou lançait la même exception car la clé privée ne pouvait pas être localisée.

boîte de dialogue d'importation de certificat


Un client devait continuer à réinstaller le certificat afin d'utiliser un programme client. Maintes et maintes fois, ils devraient réinstaller le certificat avant d'utiliser le programme. J'espère que cette réponse résout ce problème.
Pangamma

11

L'exception «La demande a été abandonnée: impossible de créer un canal sécurisé SSL / TLS» peut se produire si le serveur renvoie une réponse HTTP 401 non autorisée à la demande 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 cette configuration de 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 que le serveur attendait, ce qui a conduit le serveur à répondre à la demande avec l'erreur 401, ce qui a entraîné à son tour l'exception "Impossible de créer un canal sécurisé SSL / TLS".


1
Mon planificateur de tâches s'exécute tous les jours (pas le week-end). J'obtiens la même erreur, mais parfois ( 2 errors in 2 months). Lorsque j'obtiens l'erreur, quelques minutes plus tard, j'essaie à nouveau manuellement et tout est OK.
Kiquenet

10

Une autre cause possible de l' The request was aborted: Could not create SSL/TLS secure channelerreur est une incompatibilité entre les valeurs cipher_suites configurées de votre PC client et les valeurs que le serveur est configuré comme étant disposé et capable d'accepter . Dans ce cas, lorsque votre client envoie la liste des valeurs cipher_suites qu'il est en mesure d'accepter dans son message initial SSL de négociation / négociation SSL "Client Hello", le serveur voit qu'aucune des valeurs fournies n'est acceptable et peut renvoyer une "Alerte" "réponse au lieu de passer à 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 sur la négociation SSL qui se produit lorsque vous essayez et échouez à établir une connexion HTTPS au serveur (dans votre application C #).

Si vous êtes en mesure d'établir une connexion HTTPS réussie à partir d'un autre environnement (par exemple, la machine Windows XP que vous avez mentionnée - ou peut-être en appuyant sur l'URL HTTPS dans un navigateur non Microsoft qui n'utilise pas les paramètres de la suite de chiffrement du système d'exploitation, tels que Chrome ou Firefox), exécutez une autre trace Message Analyzer dans cet environnement pour capturer ce qui se passe lorsque la négociation SSL réussit.

J'espère que vous verrez une différence entre les deux messages Bonjour client qui vous permettront de déterminer exactement ce que l'échec de la négociation SSL entraîne son échec. Ensuite, vous devriez être en mesure d'apporter des modifications de configuration à 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 cipher_suites que votre PC utilisera:

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

Voici un résumé complet de la façon dont j'ai étudié et résolu une instance de cette variété du Could not create SSL/TLS secure channelproblème: http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in-windows.html


1
Dans mon cas, cette réponse est utile. De plus, comme je soupçonnais que mon PC client avait raté certaines suites de chiffrement, j'ai pris un raccourci et installé directement cette mise à jour Windows pour tenter ma chance ( support.microsoft.com/en-hk/help/3161639 , a besoin de redémarrer Windows) avant de vraiment démarrer La recherche de Message Analyzer s'est avérée avoir de la chance et cela a résolu mon problème, me sauvant une recherche.
sken130

1
Notez que lorsque vous testez un lien HTTPS dans des navigateurs tels que Firefox, même si vous obtenez un chiffrement différent de ceux fournis par un Windows Update donné, Windows Update vaut toujours la peine d'être essayé, car l'installation de nouveaux chiffrements affectera la négociation du chiffrement entre le PC client et le serveur, augmentant ainsi l'espoir de trouver une correspondance.
sken130

Au point de répondre à mon problème. Deux choses qui m'ont aidé à trouver les changements à apporter. 1. Suites de chiffrement prises en charge par le serveur Web: ssllabs.com/ssltest 2. Suites de chiffrement prises en charge par différentes versions de Windows: docs.microsoft.com/en-us/windows/win32/secauthn/…
Paul B.

10

La racine de cette exception dans mon cas était qu'à un moment donné du code, ce qui suit était appelé:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

C'est vraiment mauvais. Non seulement il demande à .NET d'utiliser un protocole non sécurisé, mais cela a un impact sur chaque nouvelle demande WebClient (et similaire) effectuée par la suite dans votre domaine d'application. (Notez que les demandes Web entrantes ne sont pas affectées dans votre application ASP.NET, mais les nouvelles demandes WebClient, telles que pour parler à un service Web externe, le sont).

Dans mon cas, ce n'était pas vraiment nécessaire, donc je pouvais simplement supprimer la déclaration et toutes mes autres demandes Web ont recommencé à fonctionner correctement. Sur la base de ma lecture ailleurs, j'ai appris quelques choses:

  • Il s'agit d'un paramètre global dans votre domaine d'application, et si vous avez une activité simultanée, vous ne pouvez pas lui attribuer une valeur fiable, effectuer votre action, puis la réinitialiser. Une autre action peut avoir lieu pendant cette petite fenêtre et être impactée.
  • Le paramètre correct est de le laisser 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 la mise à niveau des frameworks. Le paramétrer sur TLS12 (qui est le plus sécurisé à ce jour) fonctionnera maintenant, mais dans 5 ans, cela pourrait commencer à causer de mystérieux problèmes.
  • Si vous avez vraiment besoin de définir une valeur, vous devez envisager de le faire dans une application ou un domaine d'application séparé et trouver un moyen de parler entre celui-ci et votre pool principal. Comme il s'agit d'une valeur globale unique, essayer de la gérer dans un pool d'applications occupé ne causera que des problèmes. Cette réponse: https://stackoverflow.com/a/26754917/7656 fournit une solution possible au moyen d'un proxy personnalisé. (Notez que je ne l'ai pas personnellement implémenté.)

2
Contrairement à votre règle générale, j'ajouterai qu'il y a une exception lorsque vous DEVEZ le régler sur TLS 1.2, plutôt que de laisser l'exécution par défaut. Si vous utilisez un framework plus ancien que .NET 4.6 et que vous désactivez les protocoles non sécurisés sur votre serveur (SSL ou TLS 1.0 / 1.1), vous ne pouvez pas émettre de requêtes à moins de forcer le programme dans TLS 1.2.
Paul

10

J'ai eu ce problème car mon web.config avait:

<httpRuntime targetFramework="4.5.2" />

et pas:

<httpRuntime targetFramework="4.6.1" />

J'ai eu ce même problème et j'ai ajouté une réponse plus détaillée ci-dessous, qui va dans plus des tenants et aboutissants de ce problème.
JLRishe

9

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

Si vous définissez la valeur de WebRequest.Timeoutsur 0, c'est l'exception qui est levée. Ci-dessous est le code que j'avais ... (Sauf au lieu d'un code dur 0pour la valeur de délai d'attente, j'avais un paramètre qui a été réglé par inadvertance 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 ...

2
Hou la la! Merci d'avoir mentionné cela. Je ne pouvais pas croire cela en premier lieu et j'ai essayé des tonnes de choses différentes en premier. Enfin, définissez le délai d'attente à 10 secondes et l'exception a disparu! C'est la solution pour moi. (y)
derFunk

9

La réponse la plus votée sera probablement suffisante pour la plupart des gens. Cependant, dans certaines circonstances, vous pouvez continuer à obtenir une erreur «Impossible de créer un canal sécurisé SSL / TLS» même après avoir forcé TLS 1.2. Si oui, vous voudrez peut-être consulter cet article utilepour des étapes de dépannage supplémentaires. Pour résumer: indépendamment du problème de version TLS / SSL, le client et le serveur doivent se mettre d'accord sur une "suite de chiffrement". Pendant la phase de «prise de contact» de la connexion SSL, le client listera ses suites de chiffrement prises en charge pour que le serveur les compare à sa propre liste. Mais sur certaines machines Windows, certaines suites de chiffrement courantes peuvent avoir été désactivées (apparemment en raison de tentatives bien intentionnées de limiter la surface d'attaque), ce qui diminue la possibilité pour le client et le serveur de convenir d'une suite de chiffrement. S'ils ne peuvent pas se mettre d'accord, vous pouvez voir "code d'alerte fatale 40" dans l'observateur d'événements et "Impossible de créer un canal sécurisé SSL / TLS" dans votre programme .NET.

L'article susmentionné explique comment répertorier toutes les suites de chiffrement potentiellement prises en charge par une machine et activer des suites de chiffrement supplémentaires via le Registre Windows. Pour aider à vérifier quelles suites de chiffrement sont activées sur le client, essayez de visiter cette page de diagnostic dans MSIE. (L'utilisation du suivi System.Net peut donner des résultats plus définitifs.) Pour vérifier quelles suites de chiffrement sont prises en charge par le serveur, essayez cet outil en ligne (en supposant que le serveur est accessible sur Internet). Il va sans dire que les modifications du Registre doivent être effectuées avec prudence , en particulier lorsque le réseautage est impliqué. (Votre machine est-elle une machine virtuelle hébergée à distance? Si vous deviez interrompre la mise en réseau, la machine virtuelle serait-elle accessible du tout?)

Dans le cas de mon entreprise, nous avons activé plusieurs suites "ECDHE_ECDSA" supplémentaires via la modification du registre, pour résoudre un problème immédiat et éviter les problèmes futurs. Mais si vous ne pouvez pas (ou ne voulez pas) modifier le Registre, de nombreuses solutions de contournement (pas nécessairement jolies) vous viennent à l'esprit. Par exemple: votre programme .NET pourrait déléguer son trafic SSL à un programme Python distinct (qui peut lui-même fonctionner, pour la même raison que les demandes Chrome peuvent réussir lorsque les demandes MSIE échouent sur une machine affectée).


9

L'une des principales causes de ce problème est la version active de .NET Framework. La version d'exécution du framework .NET affecte les protocoles de sécurité activés par défaut.

Il ne semble pas y avoir de documentation faisant autorité sur la façon dont cela fonctionne spécifiquement dans différentes versions, mais il semble que les valeurs par défaut soient déterminées plus ou moins comme suit:

  • .NET Framework 4.5 et versions antérieures - SSL 3.0, TLS 1.0
  • .NET Framework 4.6.x - TLS 1.0, 1.1, 1.2, 1.3
  • .NET Framework 4.7+ - Valeurs par défaut du système (OS)

(Pour les versions plus anciennes, votre kilométrage peut varier quelque peu en fonction des environnements d'exécution .NET installés sur le système. Par exemple, il peut y avoir une situation dans laquelle vous utilisez un cadre très ancien et TLS 1.0 n'est pas pris en charge, ou utilisez 4.6. x et TLS 1.3 n'est pas pris en charge)

La documentation de Microsoft conseille fortement d'utiliser 4.7+ et les valeurs par défaut du système:

Nous vous recommandons de:

  • Ciblez .NET Framework 4.7 ou versions ultérieures sur vos applications. Ciblez .NET Framework 4.7.1 ou versions ultérieures sur vos applications WCF.
  • Ne spécifiez pas la version TLS. Configurez votre code pour laisser le système d'exploitation décider de la version TLS.
  • Effectuez un audit de code approfondi pour vérifier que vous ne spécifiez pas de version TLS ou SSL.

Pour les sites ASP.NET , vérifiez la version du framework .NET dans votre <httpRuntime>élément, car cela détermine quel runtime est réellement utilisé par votre site:

<httpRuntime targetFramework="4.5" />

Meilleur:

<httpRuntime targetFramework="4.7" />

8

Celui-ci travaille pour moi dans MVC webclient

    public string DownloadSite(string 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;
        }
    }

2
La substitution de ServerCertificateValidationCallback introduirait-elle un nouveau trou de sécurité?

7

Dans le cas où le client est une machine Windows, une raison possible pourrait être que le protocole tls ou ssl requis 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 paramètres jusqu'à "Sécurité" et choisissez entre

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

entrez la description de l'image ici


des problèmes pour les cocher tous?
Nigel Fds

pas de problème, pour autant que je sache ... sauf que ssl n'est plus recommandé ... ils ne sont pas considérés comme suffisamment sécurisés.
cnom

comment le faire par programmation en PowerShell?
Kiquenet

C'est quelque chose qui affecte les anciennes versions de Windows. Faites des recherches pour savoir quelles options de sécurité sont actuellement utilisées. À ce jour, consultez ce lien: tecadmin.net/enable-tls-on-windows-server-and-iis
Tod

7

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

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

7

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.


Hélas pas pour moi!
benedict_w

C'est le seul qui m'a aidé dans mon cas! Merci!!!
alexander ostrikov

6

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

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

Mais si j'ai rétrogradé à 4.0, j'ai de nouveau eu le même problème, et c'était irréversible pour ce projet (même lorsque j'ai essayé de passer à nouveau à 4.5).

Étrange aucun 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


5
La raison pour laquelle cela a fonctionné peut être due au fait que différentes versions de .NET prennent en charge différentes versions de protocole SSL / TLS. Plus d'infos: blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support
Jon Schneider

4

System.Net.WebException: la demande a été abandonnée: impossible de créer un canal sécurisé SSL / TLS.

Dans notre cas, nous avons utilisé un fournisseur de logiciels, nous n'avons donc pas eu accès à la modification du code .NET. Apparemment .NET 4 n'utilisera pas TLS v 1.2 sauf s'il y a un changement.

Le correctif pour nous ajoutait 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

3
Voici PS pour un montage rapide: New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value "1" -Type DWord
Tilo

2
Voici PS pour un montage rapide2: New-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value "1" -Type DWord
Tilo

4

Essaye ça:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

J'ai ajouté cette ligne. Parfois, cela échoue et j'obtiens la même erreurSystem.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
Joseph Katzman

4

Cela a été résolu pour moi, ajoutez le service réseau aux autorisations. Cliquez avec le bouton droit sur le certificat> Toutes les tâches> Gérer les clés privées ...> Ajouter ...> Ajouter "Service réseau".


3

Le problème pour moi était que j'essayais de déployer sur IIS en tant que service Web, j'ai installé le certificat sur le serveur, mais l'utilisateur qui exécute IIS n'avait pas les autorisations appropriées sur le certificat.

Comment donner à ASP.NET l'accès à une clé privée dans un certificat dans le magasin de certificats?


Oui, idem. Pour y remédier, j'ai fait ce que Nick Gotch a répondu: changer l'identité du pool d'applications en LocalSystem. Cela l'a résolu pour moi.
Judah Gabriel Himango

1
Merci pour cela
Denis Pitcher

3

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 flux nécessitaient la correction:

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

3

Cette question peut avoir de nombreuses réponses car il s'agit d'un message d'erreur générique. Nous avons rencontré ce problème sur certains de nos serveurs, mais pas sur nos machines de développement. Après avoir retiré la plupart de nos cheveux, nous avons constaté que c'était un bug de Microsoft.

https://support.microsoft.com/en-us/help/4458166/applications-that-rely-on-tls-1-2-strong-encryption-experience-connect

Essentiellement, MS suppose que vous souhaitez un cryptage plus faible, mais le système d'exploitation est corrigé pour n'autoriser que TLS 1.2, vous recevez donc le redouté "La demande a été abandonnée: impossible de créer un canal sécurisé SSL / TLS."

Il existe trois correctifs.

1) Corrigez le système d'exploitation avec la mise à jour appropriée: http://www.catalog.update.microsoft.com/Search.aspx?q=kb4458166

2) Ajoutez un paramètre à votre fichier app.config / web.config.

3) Ajoutez un paramètre de registre déjà mentionné dans une autre réponse.

Tous ces éléments sont mentionnés dans l'article de la base de connaissances que j'ai publié.


Assurez-vous également que vous ne définissez ServicePointManager.SecurityProtocol qu'une seule fois dans votre application. Nous avons découvert un deuxième appel dans notre application (qui est plutôt complexe avec des assemblages facultatifs chargés lors de l'exécution) qui le définissait sur SSL3, qui a ensuite lancé le même message d'erreur.
Michael Silver

3

Une autre possibilité est que le code en cours d'exécution n'a pas les prémisses requises.

Dans mon cas, j'ai eu cette erreur lors de l'utilisation du débogueur Visual Studio pour tester un appel à un service Web. Visual Studio ne s'exécutait pas en tant qu'administrateur, ce qui a provoqué cette exception.


2

Cela se produisait pour moi sur un seul site, et il s'avère que seul le code 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 a été résolu.


1
N'utilisez pas de liens sur la réponse, car ils peuvent ne pas fonctionner sur l'avenir, signalez les aspects les plus pertinents à l'intérieur de votre réponse
Rodrigo López
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.