Notre client a récemment mis à jour le protocole de sécurité à TLS 1.2. Par conséquent, nous avons mis notre application à niveau vers la version 4.6.1 en nous attendant à ce que le protocole de sécurité passe par défaut à TLS 1.2, mais ce n'est pas le cas. Avez-vous une idée de la raison ?
J'ai eu un problème similaire et voici ce qui a fonctionné pour moi.
ouvrir Powershell et vérifier les protocoles pris en charge en utilisant [Net.ServicePointManager]::SecurityProtocol
Exécutez les 2 cmdlets suivants pour définir Clés de registre de cryptographie forte du cadre .NET :
définir une cryptographie forte sur 64 bit .Net Framework (version 4 et plus)
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
définir une cryptographie forte sur 32 bit .Net Framework (version 4 et plus)
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Redémarrez Powershell et vérifiez à nouveau le protocole supporté en utilisant [Net.ServicePointManager]::SecurityProtocol
Il devrait maintenant afficher Tls12 également.
J'espère que cela vous aidera
Cela devrait très certainement fonctionner sur le code d'application .NET 4.x avec .NET 4.6+ installé.
Cela a fonctionné pour moi - Merci ! Au fait, si vous le pouvez, ajoutez une barre oblique inverse entre Microsoft et .NetFramework pour les autres : "Set-ItemProperty -Path 'HKL M:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319 ' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord" Les deux commandes sont également identiques. Peut-être qu'une note pourrait être faite à cet effet. Merci encore.
Merci pour les commentaires. Le 64 bits devrait également inclure la clé Wow6432node. Correction.
Comme d'autres l'ont mentionné, il existe un certain nombre de clés de registre Windows qui doivent être définies pour activer TLS 1.2 dans les applications .NET existantes sans définir explicitement la version du protocole dans le code de l'application.
Afin de faire Le code .NET 4.x sélectionne le protocole le plus puissant disponible. par défaut (c'est-à-dire lorsqu'un protocole n'est pas explicitement spécifié dans le code), les clés de registre suivantes sont nécessaires :
Sur les versions 32 et 64 bits de Windows : HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SchUseStrongCrypto: 0X00000001
Sur les versions 64 bits de Windows : HKLM\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SchUseStrongCrypto: 0X00000001
El WOW6432Node est nécessaire pour activer TLS 1.2 dans les applications 32 bits lorsqu'elles sont exécutées sur des systèmes 64 bits.
Mais voici la solution rapide et facile : https://github.com/TheLevelUp/pos-tls-patcher
Mise à jour :
Si vous ciblez .NET 4.6 ou 4.7, vous serez intéressé par les éléments suivants Meilleures pratiques en matière de sécurité de la couche de transport (TLS) avec le .NET Framework .
Notez que TLS Patcher Le lien ci-dessus suit de très près la recommandation de Microsoft pour les applications .NET 4.0 et 4.5 existantes qui ne peuvent pas cibler .NET 4.6 ou plus.
Je pense que cela devrait être la réponse acceptée. Nous avons été confrontés au même problème et avons observé ce qui suit : Un EXE .Net normal fonctionne comme prévu. Une assemblée hébergée dans un processus natif (par exemple, IIS, Office Addin) n'utilise TLS 1.2 que si les paramètres du registre ont été effectués.
@StefanEgli Je ressens votre douleur. Je ne sais pas pourquoi cette information n'est pas mieux documentée. Nous essayons de faire passer le mot : blog.thelevelup.com/pci-security-is-your-restaurant-ready
@StefanEgli également si vous voulez TLS 1.2 dans le code natif, vous devez également définir les clés de registre Schannel : docs.microsoft.com/fr/us/Windows-server/security/tls/
La raison pour laquelle le protocole de sécurité n'a pas été défini par défaut sur TLS 1.2 est qu'il n'y a pas de valeur par défaut pour cela dans .NET Framework 4.6.1. Désolé si je répète ce qui a déjà été dit, mais je voulais développer et je n'ai pas assez de réputation pour commenter.
Il n'y a pas non plus de valeur par défaut dans la version 4.6.2, mais comme l'un des commentateurs l'a mentionné ci-dessus, une application console semble utiliser TLS 1.2 par défaut. J'ai essayé exactement le même code dans un projet de site Web ciblant la version 4.6.2 et il n'y avait PAS de valeur par défaut pour TLS 1.2.
4.7 et plus ont une valeur par défaut de SecurityProtocolType.SystemDefault.
"Cela permet aux API de mise en réseau de .NET Framework basées sur SslStream (telles que FTP, HTTP et SMTP) d'hériter des protocoles de sécurité par défaut du système d'exploitation ou de toute configuration personnalisée effectuée par un administrateur système."
MSDN : Propriété ServicePointManager.SecurityProtocol
Cette propriété sélectionne la version du protocole Secure Sockets Layer (SSL) ou Transport Layer Security (TLS) à utiliser pour les nouvelles connexions. Transport Layer Security (TLS) à utiliser pour les nouvelles connexions qui utilisent uniquement le schéma Secure Hypertext Transfer Protocol (HTTPS) ; Les connexions existantes ne sont pas modifiées. Notez qu'aucune valeur par défaut n'est valeur par défaut pour cette propriété, à dessein.
Le paysage de la sécurité évolue constamment, et les protocoles et niveaux de protection par défaut sont modifiés au fil du temps en fonction des besoins. niveaux de protection sont modifiés au fil du temps afin d'éviter les faiblesses connues. faiblesses connues. Les valeurs par défaut varient en fonction de la configuration machine, des logiciels installés et des correctifs appliqués. correctifs ont été appliqués.
Tiré de aquí
Le protocole de sécurité par défaut pour .NET 4.6.1 n'est pas TLS 1.2 - Vous devez définir la valeur de ServicePointManager.SecurityProtocol pour qu'il soit pris en charge.
En quoi cela répond-il à la question ? L'OP dit que TLS1.2 n'a pas fonctionné alors qu'il aurait dû.
Je comprends la question comme suit : "Je n'ai rien fait et je m'attendais à ce que TLS 1.2 fonctionne".
J'ai également rencontré ce problème. Lorsque l'application locale essayait de se connecter à un serveur qui supporte TLS 1.1 et TLS 1.2, elle obtenait l'exception "An existing connection was forcibly closed by the remote host". ou lorsque TLS 1.1/1.2 n'était pas activé correctement, elle obtenait l'exception "Win32Exception : Le client et le serveur ne peuvent pas communiquer, car ils ne possèdent pas d'algorithme commun".
Vous trouverez ci-dessous toutes les clés de registre et les valeurs qui sont nécessaires pour le système d'exploitation Windows x64. Si vous avez un système d'exploitation 32 bits (x86), supprimez simplement les deux dernières lignes. TLS 1.0 sera désactivé par le registre script. Le redémarrage du système d'exploitation est nécessaire.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001
"enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\server]
"disabledbydefault"=dword:00000001
"enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\ssl 3.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\ssl 3.0\client]
"disabledbydefault"=dword:00000001
"enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\ssl 3.0\server]
"disabledbydefault"=dword:00000001
"enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\tls 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\tls 1.0\client]
"disabledbydefault"=dword:00000001
"enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\tls 1.0\server]
"disabledbydefault"=dword:00000001
"enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\tls 1.1]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\tls 1.1\client]
"disabledbydefault"=dword:00000000
"enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\tls 1.1\server]
"disabledbydefault"=dword:00000000
"enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\tls 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\tls 1.2\client]
"disabledbydefault"=dword:00000000
"enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\tls 1.2\server]
"disabledbydefault"=dword:00000000
"enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001 Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
Comment savez-vous que ça ne l'est pas ? Qu'avez-vous essayé ?
0 votes
TLS 1.2 fonctionne par défaut dans 4.6.2 - l'utilisation de HttpClient pour récupérer la page d'accueil de Google.com (TLS1.2) fonctionne sans problème.
1 votes
Nous obtenons cette erreur lors de la connexion au serveur "Cela pourrait être dû au fait que le certificat du serveur n'est pas configuré correctement avec HTTP.SYS dans le cas HTTPS". Cependant, l'ajout de cette ligne dans la méthode de démarrage du fichier Global.asax a permis de résoudre ce problème. ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3 ; Mais nous voulons savoir pourquoi nous devons définir cela si notre application est en .Net 4.6.1.
0 votes
Quoi Une erreur ? Quel code ? Je ne peux rien reproduire avec une application console ciblant 4.6.1. Si le certificat est erronée, vous obtiendrez une erreur avec cualquier client, y compris les navigateurs.
0 votes
Aucun reproche avec une application console ciblant 4.6.1 sur Windows 10, appelant une page web qui n'accepte que TLS1.2 avec HttpClient. En fait, si je force TLS1.1 J'obtiens
The request was aborted: Could not create SSL/TLS secure channel..0 votes
Nous avons rencontré exactement le même problème pour nous connecter à l'API Salesforce, qui a récemment commencé à exiger TLS 1.2. Même avec .NET 4.6.1, nous obtenions toujours des connexions TLS 1.0 (qui étaient ensuite rejetées). Nous avons dû spécifier manuellement le ServicePointManager.SecurityProtocol, comme vous. Je soupçonne un problème avec la façon dont l'API Salesforce autonégocie la version TLS.
0 votes
Voir ma solution ici : stackoverflow.com/a/45442874/5785572