Pourquoi la suite de chiffrement SSL de Windows est-elle restreinte sous certains certificats SSL?

Problème: Windows Server 2008 R2 prend uniquement en charge les suites de chiffrement SSL suivantes lors de l'utilisation de certains certificats sur le serveur:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

Cela empêche les clients XP de se connecter au serveur car l'API cryptographique XP ne prend en charge aucun chiffrement AES par défaut.
Par conséquent, les erreurs suivantes apparaissent dans les journaux du serveur lors de la tentative de connexion à l'aide d'Internet Explorer ou du bureau à distance. (car ils utilisent le CAPI de Microsoft)

Erreur Schannel 36874 "Une connexion TLS 1.0 a été reçue d'une application cliente distante, mais les suites de chiffrement prises en charge par le client sont prises en charge par le serveur. La demande de connexion SSL a échoué."
Erreur de canal 36888 "L'alerte fatale suivante a été générée: 40. L'état d'erreur interne est 1204"

Si le certificat utilisé sur le serveur a été généré à l'aide de l'option Clé héritée du formulaire de demande de certificat, la clé privée de ce certificat sera stockée dans l'infrastructure API cryptographique héritée de Microsoft. Lorsque le serveur Web essaie de traiter des demandes à l'aide de sa nouvelle infrastructure CNG (Cryptographic Next Generation), il apparaît que quelque chose lié à la clé privée RSA stockée dans l'infrastructure héritée n'est pas disponible pour la nouvelle infrastructure. Par conséquent, l'utilisation des suites de chiffrement RSA est sévèrement limitée.

Solution:
générez la demande de certificat à l'aide du modèle de clé CNG dans l'assistant de demande de certificat personnalisé.

MMC | Gestionnaire de certificat d'ordinateur local | Dossier de certificats personnels | (clic droit) | Toutes les tâches -> Opérations avancées | Créer une demande personnalisée | "Procéder sans politique d'inscription" | sélectionnez "(pas de modèle) clé CNG" | procéder pour compléter la demande de certificat selon vos besoins.

Vérification que la clé est au bon endroit:
http://msdn.microsoft.com/en-us/library/bb204778(VS.85).aspx
http://www.jensign.com/KeyPal/index.html

Outils pour vérifier les suites de chiffrement correctes:
http://pentestit.com/2010/05/16/ssltls-audit-audit-web-servers-ssl-ciphers/
https://www.ssllabs.com/

Paramètres de la suite de chiffrement SSL:
http://support.microsoft.com/kb/245030
http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order -in-internet-explorer-7-sur-windows-vista.aspx

Cela nous a pris une semaine pour comprendre. J'espère que cela évite à quelqu'un le même problème.

J'ai moi-même eu exactement le même problème et ce message m'a fait gagner beaucoup de temps, merci à tous!

La solution de Gary est parfaite, mais j'ai réussi à résoudre le problème simplement en convertissant le PFX en PEM, puis de nouveau en PFX en utilisant openssl. Le nouveau PFX a importé le certificat dans IIS de la même manière, à la différence près que je peux voir les chiffres manquants.

C'est ainsi:

openssl pkcs12 -in mycert.pfx -out mycert.cer -nodes

Ensuite, divisez le fichier cer en trois, la clé, le certificat et le ou les certificats intermédiaires

openssl pkcs12 -export -out mycert-new.pfx -inkey mycert.key \
-in mycert.crt -certfile mycert-intermediate.crt

Ensuite, si vous importez le nouveau fichier .pfx dans IIS, il utilisera tous les chiffres que vous attendez.

Donc pas besoin de réémettre le certificat.

Merci, votre message m'a aidé, bien que mon problème ne soit pas exactement le même.

Cependant, la cause était une erreur de configuration de l'API WINHTTP SERVER de ma part. Mon IP a changé et lorsque j'ai mis un nouveau certificat de serveur dans la machine "MY", j'ai ignoré le code de retour ALREADY_EXISTS pour HttpSetServiceConfiguration.

J'ai donc utilisé un certificat TLS de serveur précédent qui avait le mauvais nom commun et ne correspondait pas à mon nouveau nom de serveur.

Si vous ne faites pas HttpDeleteServiceConfiguration () ou la ligne de commande "netsh http delete sslcert 0.0.0.0:8443" correctement, vous obtiendrez une erreur désagréable avec ces symptômes:

1) Dans TLS, votre client Hello reçoit immédiatement un paquet TCP de votre serveur avec les bits d'indicateur Ack et Reset définis. (Une alerte d'échec de la poignée de main, je pense?)

2) L'observateur d'événements obtient "L'alerte fatale suivante a été générée: 40. L'état d'erreur interne est 107."

"Une demande de connexion SSL 3.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é."

Donc, avant de poursuivre une incompatibilité de suite de chiffrement, assurez-vous que vous utilisez vraiment le certificat de serveur que vous souhaitez utiliser avec:

         netsh http show sslcert

et vérifiez les valeurs de hachage!

Cela pourrait être le problème KeySpec = 2 - AT_SIGNATURE

certutil -verifystore -v Mon "Empreinte numérique de cert" pour vérifier la valeur de KeySpec. Si c'est le 2, vous devrez exporter le certificat en tant que fichier PFX, puis exécuter certutil -importpfx AT_KEYEXCHANGE pour le corriger.