La demande a été abandonnée: impossible de créer le canal sécurisé SSL / TLS
Nous ne pouvons 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 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 à partir d'une autre publication 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. Est-ce que quelqu'un a une idée de ce que je devrais faire?
Je dois mentionner qu'un collègue et moi avons effectué des tests il y a quelques semaines et que tout fonctionnait bien avec quelque chose de similaire à ce que j'ai écrit ci-dessus. La seule "différence majeure" que nous avons constatée est que j'utilise Windows 7 et qu'il utilisait Windows XP. Est-ce que ça change quelque chose?
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 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 marche parfaitement.
ADDENDUM
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 à compter du 3 décembre 2018. Vous devrez utiliser TLS. Voici page Paypal à ce sujet.
La solution à cela, dans .NET 4.5 est
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
Si vous ne disposez pas de .NET 4.5, utilisez
ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
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;
Le problème que vous rencontrez est que l'utilisateur aspNet n'a pas accès au certificat. Vous devez donner accès en utilisant le winhttpcertcfg.exe
Voici un exemple de configuration: http://support.Microsoft.com/kb/90118
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 du gestionnaire de certificats. Vous pouvez y accéder en cliquant avec le bouton droit de la souris 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
L'erreur est générique et la négociation SSL/TLS peut échouer pour de nombreuses raisons. Le plus commun est un certificat de serveur invalide ou arrivé à expiration, et vous vous en êtes occupé en fournissant votre propre hook 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 chiffrements non pris en charge par votre client, sa durée peut être trop longue pour que la poignée de main réussisse et bien d’autres raisons encore.
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 oeil à Outils et paramètres TLS/SSL .
Voir aussi Comment activer la journalisation d'é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 qui prend en charge des trucs fous comme SPDY et des redirections étranges SSL certs.
Au lieu de spécifier Ssl3 comme dans la réponse de Simons, j'ai pu résoudre le problème en descendant dans Tls12 comme ceci:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png");
Après de longues heures consacrées au même problème, j’ai constaté que le compte ASP.NET sous lequel le service client était exécuté 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é sur le compte LocalSystem de NetworkService.
Une meilleure solution consiste à faire fonctionner le certificat avec le compte par défaut NetworkService, mais cela fonctionne pour des tests fonctionnels rapides.
Quelque chose que la réponse originale n'avait pas. J'ai ajouté un peu plus de code pour le rendre à toute épreuve.
ServicePointManager.Expect100Continue = true;
ServicePointManager.DefaultConnectionLimit = 9999;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;
Une autre possibilité est une importation incorrecte de certificat sur la boîte. Assurez-vous de cocher la case encerclée. Au début, je ne l'avais pas fait. Le code était donc soit en cours d'expiration, soit en lançant la même exception, car la clé privée ne pouvait pas être localisée.
L'exception "La demande a été abandonnée: impossible de créer le canal sécurisé SSL/TLS" peut survenir si le serveur renvoie une réponse HTTP 401 non autorisée à HTTP. demande.
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 la section cette réponse .
Une fois que cette configuration de journalisation est 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 ne parvenais pas à définir un cookie particulier que le serveur attendait, ce qui a amené le serveur à répondre à la demande avec l'erreur 401, ce qui a entraîné l'exception "Impossible de créer le canal sécurisé SSL/TLS".
La racine de cette exception dans mon cas était qu’à un moment donné du code, l’appel suivant était appelé:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;
C'est vraiment mauvais. Non seulement cela indique à .NET d'utiliser un protocole non sécurisé, mais cela a un impact sur chaque nouvelle requête WebClient (et similaire) faite ultérieurement dans votre domaine d'application. (Notez que les demandes Web entrantes ne sont pas affectées dans votre application ASP.NET, mais que les nouvelles demandes WebClient, telles que la conversation avec un service Web externe, le sont).
Dans mon cas, ce n'était pas vraiment nécessaire, je pouvais donc simplement supprimer la déclaration et toutes mes autres requêtes Web ont recommencé à fonctionner correctement. 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, et si vous avez une activité simultanée, vous ne pouvez pas le définir de manière fiable sur une valeur, exécuter votre action, puis le rétablir. Une autre action peut avoir lieu pendant cette petite fenêtre et être impactée.
- Le réglage correct est de laisser les valeurs par défaut. Cela permet à .NET de continuer à utiliser quelle que soit la valeur par défaut la plus sécurisée au fil du temps et de mettre à niveau les infrastructures. Le paramétrer sur TLS12 (qui est le plus sûr en ce moment) 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 devez envisager de le faire dans une application ou une application distincte et séparée et trouver un moyen de communiquer entre elle 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 fera que créer 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 mis en œuvre.)
Celui-ci travaille pour moi dans le client Web MVC
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 constater, de nombreuses raisons pourraient expliquer cette situation. J'ai pensé ajouter la cause que j'ai rencontrée ...
Si vous définissez la valeur de WebRequest.Timeout sur 0, il s'agit de l'exception levée. Vous trouverez ci-dessous le code que j'avais ... (sauf qu'au lieu d'un 0 codé en dur pour la valeur de délai d'attente, j'avais un paramètre qui avait é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 ...
Une autre cause possible de l’erreur The request was aborted: Could not create SSL/TLS secure channel est un décalage entre les valeurs cipher_suites configurées de votre PC client et les valeurs configurées par le serveur comme acceptant et pouvant accepter . Dans ce cas, lorsque votre client envoie la liste des valeurs cipher_suites qu’il est capable d’accepter dans son message initial de négociation/négociation SSL "Client Hello", le serveur voit qu’aucune des valeurs fournies n’est acceptable et peut renvoyer une "Alerte". "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 un suivi sur la négociation SSL qui survient lorsque vous essayez d'établir une connexion HTTPS avec le serveur (dans votre application C #). ).
Si vous parvenez à établir une connexion HTTPS avec succès depuis un autre environnement (par exemple, la machine Windows XP que vous avez mentionnée) ou éventuellement en tapant l’URL HTTPS dans un navigateur non Microsoft qui n’utilise pas le système d’exploitation. Les paramètres de la suite de chiffrement, tels que Chrome ou Firefox), exécutent une autre trace Message Analyzer dans cet environnement pour capturer ce qui se passe lorsque la négociation SSL aboutit.
Espérons que vous constaterez une différence entre les deux messages Client Hello qui vous permettra de déterminer avec précision ce que la négociation SSL défaillante entraîne l’échec. Ensuite, vous devriez pouvoir modifier la configuration de Windows pour lui permettre 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\LOGICIEL\Stratégies\Microsoft\Cryptographie\Configuration\SSL\00010002
- HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002
Voici un récapitulatif complet de la manière dont j’ai enquêté 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- dans windows.html
Dans le cas où le client est une machine Windows, une des raisons possibles 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
- Utiliser SSL 3.0
- Utilisez TLS 1.0
- Utilisez TLS 1.1
- Utilisez TLS 1.2
J'ai lutté avec ce problème toute la journée.
Lorsque j'ai créé un nouveau projet avec .NET 4.5, je l'ai enfin fait fonctionner.
Mais si je rétrogradais à la version 4.0, je rencontrais à nouveau le même problème, qui était irréversible pour ce projet (même lorsque j’essayais à nouveau de passer à la version 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
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 est partie
- mmc
- certificats
- Étendre au personnel
- sélectionnez cert
- clic-droit
- Toutes les tâches
- Gérer les clés privées
- Ajouter
J'ai eu ce problème parce que mon web.config avait:
<httpRuntime targetFramework="4.5.2" />
et pas:
<httpRuntime targetFramework="4.6.1" />
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 le même problème et j'ai trouvé cette réponse fonctionnait correctement pour moi. La clé est 3072. Ce lien fournit des 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 le correctif:
https://www.fbi.gov/feeds/fbi-in-the-news/atom.xml
https://www.wired.com/feed/category/gear/latest/rss
Le réponse votée par le haut sera probablement suffisant pour la plupart des gens. Toutefois, dans certaines circonstances, vous pouvez continuer à obtenir l'erreur "Impossible de créer le canal sécurisé SSL/TLS" même après avoir forcé TLS 1.2. Si tel est le cas, vous pouvez consulter cet article utile pour connaître les étapes de dépannage supplémentaires. En résumé: indépendamment du problème de version TLS/SSL, le client et le serveur doivent s’accorder sur une "suite de chiffrement". Au cours de la phase de "liaison" de la connexion SSL, le client répertorie les suites de chiffrement prises en charge que le serveur vérifie par rapport à sa propre liste. Toutefois, 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 réduit le risque que le client et le serveur s'accordent sur une suite de chiffrement. S'ils ne peuvent pas accepter, vous pouvez voir "le code d'alerte irrécupérable 40" dans l'afficheur d'événements et "Impossible de créer le 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 d'un ordinateur et activer des suites de chiffrement supplémentaires via le registre Windows. Pour vérifier quelles suites de chiffrement sont activées sur le client, essayez de visiter cette page de diagnostic dans MSIE. (L'utilisation du traçage 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 à Internet). Il va sans dire que les modifications du registre doivent être effectuées avec prudence , en particulier lorsque la mise en réseau est impliquée. (Votre machine est-elle une machine virtuelle hébergée à distance? Si vous deviez interrompre la mise en réseau, la VM serait-elle accessible?)
Dans le cas de ma société, nous avons activé plusieurs suites supplémentaires "ECDHE_ECDSA" via la modification du registre, afin de résoudre un problème immédiat et d'éviter les problèmes futurs. Mais si vous ne pouvez pas (ou ne voulez pas) éditer le registre, de nombreuses solutions de contournement (pas nécessairement jolies) vous viennent à l’esprit. Par exemple: votre programme .NET peut 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 aboutir là où les demandes MSIE échouent machine affectée).
System.Net.WebException: la demande a été abandonnée: impossible de créer le canal sécurisé SSL/TLS.
Dans notre cas, nous utilisions un éditeur de logiciels, nous n'avions donc pas le droit de modifier le code .NET. Apparemment, .NET 4 n'utilisera pas TLS v 1.2 sauf en cas de changement.
Le correctif pour nous consistait à ajouter 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. Cela 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
Essaye ça:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
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 le bon autorisations sur le certificat.
Comment donner à ASP.NET l'accès à une clé privée dans un certificat du magasin de certificats?
Cette question peut avoir beaucoup de réponses puisqu'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 tiré la plupart de nos cheveux, nous avons découvert qu'il s'agissait d'un bogue Microsoft.
Pour l'essentiel, MS suppose que vous souhaitez un cryptage plus faible, mais le système d'exploitation ne contient que des correctifs pour autoriser TLS 1.2. Vous recevez donc le message redouté "La requête a été abandonnée: impossible de créer un canal sécurisé SSL/TLS."
Il y a trois corrections.
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é.
Dans mon cas, j'ai eu ce problème lorsqu'un service Windows a tenté 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 à ajouter une entrée de registre dans Windows. Après avoir ajouté le registre suivant, tout fonctionne correctement.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman]
"ClientMinKeyBitLength" = dword: 00000200
Apparemment, cela est lié à une valeur manquante dans la négociation https du côté client.
Répertoriez votre correctif Windows:
wmic qfe list
Fil de solution:
https://communities.vmware.com/message/2604912#2604912
J'espère que ça aide.
Cela se produisait pour moi sur un seul site, et il s'avère que seul le chiffrement RC4 était disponible. Dans un effort précédent pour renforcer le serveur, j'avais désactivé le chiffrement RC4. Une fois réactivé, le problème a été résolu.
Vous pouvez essayer d’installer un certificat de démonstration (certains fournisseurs de ssl le proposent gratuitement pendant un mois) pour vérifier si le problème est lié à la validité de la certification ou non.
En plus des réponses ci-dessus, assurez-vous que vous avez importé le certificat CER et PAS le fichier PFX dans votre magasin d’ordinateur local. Une erreur commune lorsque vous avez les deux fichiers.
Tant que ce lien est relativement "vivant", je pensais ajouter une nouvelle option. Cette possibilité est que le service ne prend plus en charge 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 j'ai 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
Cela a corrigé pour moi, ajouter le service réseau aux autorisations. Cliquez avec le bouton droit sur certificat> Toutes les tâches> Gérer les clés privées> Ajouter> Service réseau
Aucune des réponses n'a fonctionné pour moi.
C'est ce qui a fonctionné:
Au lieu d’initialiser mon X509Certifiacte2 comme ceci:
var certificate = new X509Certificate2(bytes, pass);
Je l'ai fait comme ça:
var certificate = new X509Certificate2(bytes, pass, X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable);
Remarquez leX509KeyStorageFlags.Exportable!!
Je n'ai pas changé 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 soient nécessaires ...
Le .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 dont la valeur par défaut est TLSv1.2. Vous pouvez configurer le ServicePointManager.SecurityProtocol pour utiliser le protocole approprié pris en charge par votre serveur Web ou modifier votre configuration Apache pour autoriser tous les protocoles comme celui-ci SSLProtocolall.
J'ai rencontré le même problème récemment. Mon environnement fonctionne sous .NET 4.6.1 avec VB.NET. C'est comme ça que je l'ai corrigé:
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 certificate As X509Certificate, ByVal chain As X509Chain, ByVal sslPolicyErrors As SslPolicyErrors) As Boolean
Return True
End Function
Si vous ne voulez pas, ne pouvez pas facilement ou ne pouvez pas corriger rapidement votre code, vous pouvez forcer l'utilisation de TLS 1.2 par votre code .NET dans la structure.
Ce n'est pas mon application, mais cela a aidé le correctif de notre ancienne application .NET 4.5 (fonctionnant sur Server 2008r2) à fonctionner de nouveau avec Paypal Payflow Gateway. Ils doivent avoir commencé à forcer les connexions vers TLS 1.2 sur les rappels de passerelle de flux de paiement entre 6/25/18 et 7/8/18.
Détails: https://github.com/TheLevelUp/pos-tls-patcher Télécharger: https://github.com/TheLevelUp/pos-tls-patcher/releases
J'avais cert en magasin et au dossier. J'ai essayé de me connecter avec le fichier et j'ai reçu ce message d'erreur. Quand j'ai utilisé celui dans le magasin cela a fonctionné. Ma meilleure hypothèse est qu’une sorte de conflit est apparu du fait que le certificat était en magasin lorsque je voulais utiliser celui qui était au dossier. (Un service différent sur la même machine utilisait le cert en magasin et j'avais développé un service différent en utilisant le cert sur fichier. Travaillait comme un charme sur dev jusqu'au test).