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

https://stackoverflow.com/questions/2859790

30-09-2019
|

Question

Nous ne pouvons pas se connecter à un serveur HTTPS à l'aide WebRequest en raison de ce message d'erreur:

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

Nous savons que le serveur ne dispose pas d'un 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 poste 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 valide jamais le certificat et échoue avec l'erreur ci-dessus. Est-ce que quelqu'un a une idée de ce que dois-je faire?

Je dois mentionner qu'un collègue et moi ont effectué des tests il y a quelques semaines et il fonctionnait très bien avec quelque chose de semblable à ce que je l'ai écrit ci-dessus. La seule « grande différence » que nous avons trouvé est que je suis sous Windows 7 et il utilisait Windows XP. Est-ce que quelque chose de changement?

La solution

J'ai finalement trouvé la réponse (je ne l'ai pas noté ma source, mais il était d'une recherche);

Alors que le code fonctionne sous Windows XP, 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 français; si vous obtenez ce problème lors de la configuration PayPal, s'il vous plaît noter qu'ils ne soutiendra pas SSL3 à partir de Décembre, 3 2018. Vous aurez besoin d'utiliser TLS. Voici Paypal à ce sujet.

Autres conseils

La solution à ce, dans 4,5 .NET est

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Si vous n'avez pas 4,5 .NET puis utilisez

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

Assurez-vous que les paramètres de ServicePointManager sont faits avant le HttpWebRequest est créé, sinon il 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/")

Ne parvient pas:

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

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

Le problème que vous rencontrez est que l'utilisateur ASPNET ne dispose pas d'accès au certificat. Vous devez donner accès à l'aide du WinHttpCertCfg.exe

Un exemple sur la façon de mettre en place est à l'adresse: http://support.microsoft.com/kb/901183

En vertu de l'étape 2 dans de plus amples informations

EDIT: Dans les versions plus récentes d'IIS, cette fonctionnalité est intégrée dans le gestionnaire de certificats outil - et sont accessibles par un clic droit sur le certificat et l'utilisation de l'option pour la gestion des clés privées. Plus de détails ici:

L'erreur est générique et il y a plusieurs raisons pour lesquelles la négociation SSL / TLS peut échouer. Le plus commun est un certificat de serveur non valide ou périmé, et vous avez pris soin de cela en fournissant votre propre crochet de validation du certificat de serveur, mais pas nécessairement la seule raison. Le serveur peut exiger une authentification mutuelle, il peut être configuré avec des suites de chiffrements non pris en charge par votre client, il peut avoir une dérive de temps trop grand pour la poignée de main pour réussir et bien d'autres raisons.

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

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

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 supports des trucs dingues comme SPDY et certs étranges redirect SSL.

Au lieu de spécifier ssl3 comme dans Simons réponse que j'ai pu réparer en allant jusqu'à Tls12 comme ceci:

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

Après de longues heures avec ce même problème que je trouve que le compte ASP.NET le service client est en cours d'exécution en vertu n'a pas eu accès au certificat. Je l'ai fixé en allant dans le pool d'applications IIS que l'application web fonctionne sous, d'entrer dans les paramètres avancés, et changer l'identité du compte LocalSystem de NetworkService.

Une meilleure solution est d'obtenir le certificat de travail avec le compte NetworkService par défaut mais cela fonctionne pour le test fonctionnel rapide.

Quelque chose la réponse originale n'a pas. Je glissai plus de code pour faire preuve de balle.

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

Une autre possibilité est une mauvaise importation de certificat sur la boîte. Assurez-vous de choisir case à cocher encerclée. Au départ, je ne le faisais pas, si le code était soit le délai ou lancer même exception que la clé privée ne pouvait pas se trouver.

boîte de dialogue d

La « La demande a été annulée: Impossible de créer SSL / TLS canal sécurisé » exception peut se produire si le serveur renvoie un HTTP 401 Non autorisé réponse à la requête HTTP

Vous pouvez déterminer si cela se produit en tournant sur l'enregistrement des System.Net au niveau de trace pour votre application cliente, comme décrit dans cette réponse .

Une fois que la configuration de l'exploitation forestière est en place, lancez l'application et reproduire l'erreur, puis regardez dans la sortie de journalisation pour une ligne comme ceci:

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

Dans ma situation, je ne parvenait pas à définir un cookie particulier que le serveur attendait, ce qui conduit au serveur de répondre à la demande avec l'erreur 401, qui à son tour conduit à la « Impossible de créer SSL / TLS canal sécurisé » exception.

La racine de cette exception dans mon cas est que à un moment donné dans le code ci-après a été appelé:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Ceci est vraiment mauvais. Non seulement est-il instruisait .NET d'utiliser un protocole non sécurisé, mais cela a un impact chaque nouveau WebClient (et similaire) demande faite par la suite au sein de votre appdomain. (Notez que les requêtes Web entrantes ne sont pas affectés dans votre application ASP.NET, mais les nouvelles demandes de WebClient, comme parler à un service Web externe, sont).

Dans mon cas, il n'a pas été réellement nécessaire, pour que je puisse simplement supprimer la déclaration et toutes mes autres requêtes Web a commencé à travailler bien à nouveau. Sur la base de ma lecture ailleurs, j'ai appris quelques petites choses:

Ceci est un paramètre global dans votre appdomain, et si vous avez une activité concurrente, vous ne pouvez pas fiable le mettre à une valeur, faire votre action, puis le remettre. Une autre action peut avoir lieu pendant cette petite fenêtre et être impacté.
Le réglage correct est de le laisser par défaut. Cela permet .NET de continuer à utiliser tout ce qui est la plus grande valeur par défaut sûre que le temps passe et vous mettez à niveau des cadres. Réglage à TLS12 (ce qui est le plus sûr de cette écriture) fonctionnera maintenant , mais en 5 ans peut commencer à causer des problèmes mystérieux.
Si vous avez vraiment besoin de définir une valeur, vous devriez envisager de le faire dans une application spécialisée distincte ou appdomain et trouver un moyen de parler entre elle et votre piscine principale. Parce qu'il est une seule valeur globale, en essayant de le gérer dans un pool d'applications occupé seulement conduire à des problèmes. Cette réponse: https://stackoverflow.com/a/26754917/7656 offre une solution possible au moyen d'un proxy personnalisé . (Notez que je ne l'ai pas personnellement implémenté.)

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;
        }
    }

Comme vous pouvez le dire il y a beaucoup de raisons que cela pourrait se produire. Je pensais que ajouterais la cause que je rencontre ...

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 au lieu d'un 0 codé en dur pour la valeur de délai d'attente, j'avais un paramètre qui a été par mégarde 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 ...

Une autre cause possible de l'erreur de The request was aborted: Could not create SSL/TLS secure channel est un non-concordance entre votre valeurs du client PC de cipher_suites configurés, et les valeurs que le serveur est configuré comme étant prêt 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 handshake SSL initial / négociation « Client Bonjour », le serveur voit qu'aucune des valeurs fournies sont acceptables, et peut renvoyer une « alerte "réponse au lieu de passer à l'étape « serveur Bonjour » de la poignée de main 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 ne parviennent pas à établir une connexion HTTPS au serveur (dans votre application C #).

Si vous êtes en mesure d'établir une connexion HTTPS réussie d'un autre environnement (par exemple la machine Windows XP que vous avez mentionné - ou peut-être en tapant l'URL HTTPS dans un navigateur non-Microsoft qui n'utilise pas les paramètres de suite de chiffrement de l'OS , 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.

Si tout va bien, vous verrez une différence entre les deux messages Hello client qui vous permettra de déterminer exactement ce que sur l'échec de la négociation SSL est à l'origine à l'é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 de logiciel \ Policies \ Microsoft \ Cryptography \ Configuration \ SSL \ 00010002
HKLM \ SYSTEM \ CurrentControlSet \ Control \ Cryptography \ Configuration \ Local \ SSL \ 00010002

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

J'ai eu du mal à ce problème toute la journée.

Quand je créé un nouveau projet avec 4,5 .NET je enfin mis au travail.

Mais si je rétrogradé à 4,0 je suis arrivé à nouveau le même problème, et il a été irreversable pour ce projet (même si je l'ai essayé de passer à 4,5 fois).

Etrange aucun autre message d'erreur, mais « La demande a été abandonnée. Impossible de créer SSL / TLS canal sécurisé » est venu pour cette erreur

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

Cela peut être réglée:

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

vers le bas de la Faites défiler jusqu'à « Sécurité » et choisir entre

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

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

<httpRuntime targetFramework="4.5.2" />

et non:

<httpRuntime targetFramework="4.6.1" />

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

mmc
certificats
Développer pour personnel
sélectionnez cert
clic droit
Toutes les tâches
Gérer les clés privées
Ajouter

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

Je faisais ce même problème et trouvé cette réponse a bien fonctionné 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 requis 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 demande a été abandonnée: Impossible de créer SSL / TLS canal sécurisé.

Dans notre cas, nous où l'utilisation d'un fournisseur de logiciels de sorte que nous n'avons pas eu accès à modifier le code .NET. Apparemment, .NET 4 ne sera pas utiliser le protocole TLS v 1.2 moins qu'il y ait un changement.

Le correctif pour nous ajoutais la clé SchUseStrongCrypto au Registre. Vous pouvez copier / coller le dessous de code dans un fichier texte avec l'extension .reg et l'exécuter. Il a servi notre « 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

Essayez ceci:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Le haut voté réponse sera probablement suffisant pour la plupart des gens. Cependant, vous pouvez continuer dans certaines circonstances, message d'erreur « Impossible de créer SSL / TLS canal sécurisé », même après avoir forcé TLS 1.2. Si oui, vous pouvez consulter ce utile article pour connaître les étapes de dépannage supplémentaires. Pour résumer: indépendamment de la question de la version TLS / SSL, le client et le serveur doivent se mettre d'accord sur une « suite de chiffrement. » Au cours de la phase « poignée de main » de la connexion SSL, le client liste de ses suites de chiffrement-prises en charge par le serveur pour vérifier contre sa propre liste. Mais sur certaines machines Windows, certains algorithmes de chiffrement suites communes peuvent avoir été désactivées (apparemment en raison de tentatives bien intentionnés à la surface d'attaque de limite), ce qui diminue la possibilité du client et serveur d'accord sur une suite de chiffrement. Si elles 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 SSL / TLS canal sécurisé » dans votre programme .NET.

L'article ci-dessus explique comment lister toutes les suites de chiffrement potentiellement pris en charge d'une machine et permettre des suites de chiffrement supplémentaires par le Registre de Windows. Pour vérifier d'aide qui les suites de chiffrement sont activées sur le client, essayez de visiter cette Page de diagnostic en MSIE . (L'utilisation System.Net traçage peut donner des résultats plus définitifs.) Pour vérifier les suites de chiffrement sont pris en charge par le serveur, essayez cet outil en ligne (en supposant que le serveur est accessible par Internet). Il va sans dire que les modifications du Registre doit être fait avec précaution , en particulier lorsque la mise en réseau est impliqué. (Est-ce votre machine une machine virtuelle? Si vous étiez hébergé à distance pour briser la mise en réseau, la machine virtuelle serait accessible à tous?)

Dans le cas de mon entreprise, nous avons permis à plusieurs suites « ECDHE_ECDSA » supplémentaires par modification du Registre, pour résoudre un problème immédiat et se prémunir contre les problèmes futurs. Mais si vous ne pouvez pas (ou pas) modifier le Registre, puis de nombreuses solutions de contournement (pas nécessairement assez) viennent à l'esprit. Par exemple:. Votre programme .NET peut déléguer son trafic SSL à un programme Python distinct (qui peut travailler lui-même, pour la même raison que les demandes Chrome peuvent réussir là où les demandes MSIE échouent sur une machine affectée)

La question pour moi était que je tentais 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'a pas les autorisations correctes sur le certificat.

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

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

ID d'événement 36888 (Schannel) est élevé:

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

Enfin, il a été lié avec un correctif Windows. Dans mon cas: KB3172605 et KB3177186

La solution proposée dans le forum vmware était ajouter une entrée de registre dans les fenêtres. Après avoir ajouté le registre suivant tout va bien de travaux.

[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 dans le côté client.

Liste Windows HotFix:

wmic qfe list

Solution Discussion:

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

Hope il est aide.

Aucune des réponses de travail pour moi.

est ce qui a fonctionné:

Au lieu d'initialiser mon X509Certifiacte2 comme ceci:

   var certificate = new X509Certificate2(bytes, pass);

Je l'ai fait comme ceci:

   var certificate = new X509Certificate2(bytes, pass, X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable);

Notez que le X509KeyStorageFlags.Exportable !!

Je ne modifiait pas le reste du code (le WebRequest lui-même):

// I'm not even sure the first two lines are necessary:
ServicePointManager.Expect100Continue = true; 
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

request = (HttpWebRequest)WebRequest.Create(string.Format("https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", server));
request.Method = "GET";
request.Referer = string.Format("https://hercules.sii.cl/cgi_AUT2000/autInicio.cgi?referencia=https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", servidor);
request.UserAgent = "Mozilla/4.0";
request.ClientCertificates.Add(certificate);
request.CookieContainer = new CookieContainer();

using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
{
    // etc...
}

En fait, je ne suis même pas sûr que les deux premières lignes sont nécessaires ...

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

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

Pour l'essentiel, MS suppose que vous voulez le cryptage plus faible, mais le système d'exploitation est patché seulement permettre TLS 1.2, vous recevez le redoutée « La demande a été annulée. Impossible de créer SSL / TLS canal sécurisé »

Il y a trois corrections.

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

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

3) Ajouter un paramètre de registre qui a déjà été mentionné dans une autre réponse.

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

Vous pouvez essayer d'installer un certificat de démonstration (certains fournisseurs de ssl offre les gratuitement pendant un mois) pour être sûr que si le problème est lié à la validité de cert ou non.

Tant que ceci est un lien relativement « en direct » Je pensais que je voudrais ajouter une nouvelle option. Cette possibilité est que le service ne supporte SSL 3.0 en raison du problème avec l'attaque de caniche. Consultez la déclaration de Google à ce sujet. J'ai rencontré ce problème avec plusieurs services Web à la fois et quelque chose réalisé qu'il devait être en cours. Je suis passé à TLS 1.2 et tout fonctionne à nouveau.

http: //googleonlinesecurity.blogspot. com / 2014/10 / ce-Caniche-piqûres-exploitation-ssl-30.html

Ce qui se passait pour moi sur un seul site, et il se trouve qu'il n'avait le RC4 chiffre disponible. Dans un effort avant de durcir le serveur, j'avais désactivé le chiffrement RC4, une fois que je réactivées ce le problème a été résolu.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow