Windows Server 2003 à 2008 sslstream Aucun algorithme commun

J'ai trouvé mon problème avec la question précédente que j'ai posée.Windows Server 2003 à 2008 sslstream Aucun algorithme commun

Il semble que lors de la connexion entre Windows Server 2003 et 2008 en utilisant SSLSTREAM en C#, les serveurs ne sont pas en mesure de se mettre d'accord sur un algorithme commun.

L'exception exacte SSPI que je reçois est:

"The client and server cannot communicate, because they do not possess a common algorithm"

J'ai essayé d'utiliser SSL2, SSL3, TLS1. J'ai essayé d'utiliser Default, j'ai essayé d'installer le correctif AES SSL pour le serveur 2003. Il semble que peu importe ce que je fais, il n'y a pas d'algorithmes communs ..

Est-ce que quelqu'un sait comment résoudre ce problème?

Aussi, lorsque je tente le même code sur Windows 7 Serveur/Client d'accord sur: Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)

qui a été prise de Wireshark.

Windows Server 2003 ne dispose pas de chiffre, mais il devrait avoir certains qui sont compatibles sans avoir à activer celles indiquées ici:

http://technet.microsoft.com/en-us/library/cc766285(WS.10).aspx

Merci pour toute aide

Source

2010-11-30 Chris

J'ai essayé de changer l'élément de stratégie de groupe pour autoriser tous les chiffrements de win2k3 mais pas de chance. – Chris

Je ne sais pas si cela va résoudre votre problème, mais peut-être qu'il vaut la peine d'essayer http://support.microsoft.com/kb/245030 (Comment restreindre l'utilisation de certains algorithmes et protocoles cryptographiques dans Schannel.dll) –

Eh bien, que montre wireshark pour le cas qui a échoué? Est-ce que le serveur envoie un certificat dans son serveur bonjour? –

je ne peux pas à partir de votre question de quel côté est le serveur et qui est le client, et peut-être que cela n'a pas d'importance. Bien que je ne sois pas si familier avec ces serveurs, j'ai vu des erreurs similaires lorsque le serveur n'est pas capable de trouver sa clé privée RSA, soit en raison d'une mauvaise configuration ou plus souvent d'un malentendu. Le serveur doit avoir accès à à la fois une clé privée et sa clé publique correspondante (contenue dans son certificat) afin de terminer une connexion authentifiée.

Source

2010-11-30 22:02:51

Client: Win2k3 Serveur: Wink2k8. Le certificat que j'utilisais était auto-signé, et ce n'était pas moi qui l'avais fait. Il est protégé par un mot de passe (PK embedded?) Je semble enfin avoir réussi à ce travail en générant un nouvel ensemble de certificats en utilisant makecert. Est-il possible que le certificat que j'utilisais ait empêché l'utilisation de certains chiffrements? – Chris

ahh, ça pourrait être aussi. Je me souviens aussi vaguement que certains produits peuvent générer des certificats et des clés DSA au lieu de RSA. Ceux-ci pourraient également entraîner le message d'erreur que vous voyez. Je saurais si j'ai regardé le fichier de capture wireshark. –

Merci beaucoup pour votre aide. Je vais essayer de simuler ce qui s'est passé avant et afficher les résultats. J'ai remarqué qu'avant, j'utilisais un certificat racine CA. Les certs précédents utilisaient aussi md5/rsa pour l'algorithme, le hash et l'empreinte digitale. Quand j'en ai créé de nouveaux, j'utilise Sha1/RSA pour eux. – Chris

Le serveur a probablement tenté de négocier une connexion SSLv3.0 avec un chiffrement AES. Cette combinaison est techniquement illégale. Voir http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx?Redirected=true

Source

2014-04-01 16:06:24 EricLaw

Windows Server 2003 à 2008 sslstream Aucun algorithme commun

Répondre

Questions connexes