Aucune des suites de chiffrement prises en charge par l'application client n'est prise en charge par le serveur


9

Je reçois cette erreur dans le journal des événements Windows de mon serveur:

Une demande de connexion TLS 1.0 a été reçue d'une application cliente distante, mais aucune des suites de chiffrement prises en charge par l'application cliente n'est prise en charge par le serveur. La demande de connexion SSL a échoué.

Lorsque j'essaie de me connecter à un service Web sur une boîte Windows 7 à partir d'une boîte Windows Server 2003.

Comment ajouter une suite de chiffrement à une que l'autre prend en charge?

(réparer les clients est idéal, mais à défaut d'une solution de serveur est bien - j'ai accès à toutes les boîtes impliquées, je veux juste un chiffrement de base entre eux pour la confidentialité).

Parallèlement à des heures de recherche sur Google et de lecture, j'ai essayé:

  • Observateur d'événements Windows du serveur vérifié (erreur de suite de chiffrement trouvée)
  • Ajout de suites de chiffrement à test1 à partir de http://support.microsoft.com/kb/948963 (n'a pas aidé)
  • Ajout de TLS 1.0 aux protocoles des suites de chiffrement dans le registre Windows du serveur (aucun changement)
  • Installer les outils IIS en espérant ajouter plus de protocoles à Schannel (ce n'est pas le cas)
  • Exporter le certificat pour les clients, encore une fois, mais avec une clé privée incluse (pas de changement)
  • Vérifiez que les suites de chiffrement installées correspondent sur le serveur et le client (impossible de trouver où win2k3 les répertorie)
  • Ajoutez TLS_RSA_WITH_AES_256_CBC_SHA (installé par le correctif ci-dessus) aux suites de chiffrement du serveur (non, déjà là-bas)

@sohnee serverfault.com/questions/166750/… La réponse de Gary à cette question va en quelque sorte répondre à ce détail.
Drifter104

Vous le savez probablement déjà, mais je le publierai quand même pour ceux qui ne le savent peut-être pas. Windows 2003 n'est plus pris en charge par Microsoft et ne recevra plus de mises à jour. Si vous utilisez 2k3, vous devez migrer ou mettre à niveau.
Liczyrzepa

Ce problème est également visible sur Server 2008 (et probablement 2012 même si je n'ai pas encore de SSL sur 2012 ici).
Fenton

Réponses:


5

Windows 7 utilise la nouvelle API CNG (Cryptography Next Generation) lors du choix des chiffres. Pour autant que je sache, le GNC pour Windows 2003 n'est pas disponible.

Vous pouvez cependant installer ces suites de chiffrement basées sur AES pour une utilisation sur Windows 2003:

  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA

Ce sont les premières suites que les clients Windows Vista et Windows 7 essaieront de négocier pour une utilisation avec TLS 1.0 et supérieur, et sont également pris en charge par les clients OpenSSL.

Pour les utiliser, installez KB948963


1
Merci! J'aurais dû mentionner que j'ai déjà essayé cela - cela n'a pas résolu le problème pour moi. Peut-être que l'autre boîte les rejette toujours parce que la SRC n'est plus considérée comme sûre? Ils figurent dans sa liste de suites de chiffrement, alors que puis-je faire d'autre? :(
MGOwen

Intéressant sur le fonctionnement de la communauté. Maintenant, la meilleure réponse à cette question est celle qui n'a jamais fonctionné, et la vraie réponse est rétrogradée ... Je suppose que SHA1 est obsolète quelques années après que cette question ait été oubliée depuis longtemps. Espérons que cette réponse aide quelqu'un - ou personne n'est plus obligé de prendre en charge les serveurs 2k3 ...
MGOwen

1
@MGOwen Je suis désolé de ne pas avoir pu vous aider. J'ai personnellement résolu un problème similaire au vôtre, avec le correctif auquel je suis lié. Espérons que les votes positifs reflètent le nombre de personnes qui ont trouvé cette réponse utile
Mathias R. Jessen

-1

La solution était de générer à nouveau mon certificat, cette fois en forçant RSA et SHA1 (bien que SHA1 soit par défaut de toute façon). Pour une raison quelconque, Win Server 2k3 n'a pas pu ou ne voulait pas utiliser les bons chiffres avec un certificat makecert par défaut. Voici la ligne de commande qui a fonctionné pour moi:

makecert -pe -r -ss my -sr localMachine -n ​​"CN = domainnameoripaddressgoeshere.com" -e 01/01/2098 -a sha1 -eku 1.3.6.1.5.5.7.3.1 -sky exchange -sp "Microsoft RSA SChannel Fournisseur cryptographique "-sy 12

Pour plus de détails, voir http://mgowen.com/2013/06/19/cipher-suites-issue/ et http://msdn.microsoft.com/en-us/library/bfsktky3(v=vs.110).aspx .


3
sha1 est obsolète. Je suppose que le problème est survenu parce que tous les chiffres pris en charge par votre client 2003 sont obsolètes en raison des développements de sécurité au cours des deux dernières années. Votre réouverture de ces chiffres est susceptible d'ouvrir des trous de sécurité. Notez également que Google vous pénalisera si vous utilisez SHA1 pour un certificat de site Web. community.qualys.com/blogs/securitylabs/2014/09/09/…
mc0e

1
L'expression "SHA1 devrait être la valeur par défaut de toute façon" est probablement vraie dans le contexte que vous utilisiez probablement, mais comme l'a dit @ mc0e, elle est déconseillée en raison de problèmes de sécurité, et de nos jours, cette expression ferait frissonner le dos des professionnels de l'informatique et de la sécurité. . Assurez-vous d'utiliser SHA-2 (SHA-256) autant que possible, car c'est la norme maintenant.
rubynorails

Merci rubynorails. J'ai édité ma réponse, je voulais dire que SHA1 était la valeur par défaut sur makecert (en 2013 quand j'ai écrit cela, je ne sais pas s'il existe des versions plus récentes de makecert pour lesquelles ce n'est plus le cas). Je vais voir si nous utilisons toujours SHA1 et envisager de voir s'il vaut la peine d'essayer de demander à makecert d'utiliser autre chose et de refaire nos certificats (ce n'est pas pour un produit public).
MGOwen

Pour que Server2003 SP2 accepte (vérifie) un certificat SHA-256, il requiert un autre support de correctif.microsoft.com/en-us/kb/938397 . (XP SP2 a également exigé cela, mais il a obtenu SP3 avec le correctif avant la fin du support.)
dave_thompson_085
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.