Warum wird die SSL Cipher-Suite von Windows unter bestimmten SSL-Zertifikaten eingeschränkt?

Problem: Windows Server 2008 R2 unterstützt nur die folgenden SSL-Verschlüsselungssammlungen, wenn bestimmte Zertifikate auf dem Server verwendet werden:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

Dadurch wird verhindert, dass XP-Clients eine Verbindung zum Server herstellen, da die XP Cryptographic API standardmäßig keine AES-Verschlüsselungen unterstützt.
Infolgedessen werden die folgenden Fehler in den Serverprotokollen angezeigt, wenn versucht wird, über den Internet Explorer oder den Remotedesktop eine Verbindung herzustellen. (Da sie Microsoft CAPI verwenden)

Schannel Error 36874 "Eine TLS 1.0-Verbindung wurde von einer Remoteclientanwendung empfangen, aber einige der vom Client unterstützten Cipher Suites werden vom Server unterstützt. Die SSL-Verbindungsanforderung ist fehlgeschlagen."
Schannel Error 36888 "Die folgende schwerwiegende Warnung wurde generiert: 40. Der interne Fehlerstatus ist 1204"

Wenn das auf dem Server verwendete Zertifikat mit der Option Legacy-Schlüssel im Zertifikatanforderungsformular generiert wurde, wird der private Schlüssel für dieses Zertifikat im Legacy-Kryptografie-API-Framework von Microsoft gespeichert. Wenn der Webserver versucht, Anforderungen mit seinem neuen CNG-Framework (Cryptographic Next Generation) zu verarbeiten, ist anscheinend etwas, das mit dem im Legacy-Framework gespeicherten privaten RSA-Schlüssel zusammenhängt, für das neue Framework nicht verfügbar. Infolgedessen ist die Verwendung der RSA-Verschlüsselungssuiten stark eingeschränkt.

Lösung:
Generieren Sie die Zertifikatanforderung mithilfe der CNG-Schlüsselvorlage im Assistenten für benutzerdefinierte Zertifikatanforderungen.

MMC | Zertifikatmanager für lokalen Computer | Persönlicher Zertifikatsordner | (rechter Mausklick) | Alle Aufgaben -> Erweiterte Operationen | Benutzerdefinierte Anfrage erstellen | Msgstr "Ohne Registrierungsrichtlinie fortfahren" | Wählen Sie "(keine Vorlage) CNG-Schlüssel" | Fahren Sie fort, um die Zertifikatsanforderung gemäß Ihren Anforderungen abzuschließen.

Überprüfen, ob sich der Schlüssel an der richtigen Stelle befindet:
http://msdn.microsoft.com/en-us/library/bb204778(VS.85).aspx
http://www.jensign.com/KeyPal/index.html

Tools zur Überprüfung der korrekten Cipher-Suites:
http://pentestit.com/2010/05/16/ssltls-audit-audit-web-servers-ssl-ciphers/
https://www.ssllabs.com/

Einstellungen für die SSL-Verschlüsselungssuite:
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-on-windows-vista.aspx

Wir haben eine Woche gebraucht, um das herauszufinden. Ich hoffe, das erspart jemandem die gleichen Probleme.

Ich habe genau das gleiche Problem selbst und dieser Beitrag hat mir eine Menge Zeit gespart. Vielen Dank an alle!

Garys Lösung ist genau richtig, aber ich habe es geschafft, das Problem einfach zu lösen, indem ich die PFX in PEM konvertierte und dann mit openssl wieder zu PFX zurückkehrte. Die neue PFX hat das Zertifikat trotzdem in IIS importiert, mit dem Unterschied, dass ich die fehlenden Chiffren sehen kann.

Das ist wie:

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

Teilen Sie dann die cer-Datei in drei Teile auf: den Schlüssel, das Zertifikat und das Zwischenzertifikat.

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

Wenn Sie dann die neue PFX-Datei in IIS importieren, werden alle erwarteten Verschlüsselungen verwendet.

Das Zertifikat muss also nicht erneut ausgestellt werden.

Danke, Ihr Beitrag hat mir geholfen, obwohl mein Problem nicht genau das gleiche war.

Die Ursache war jedoch ein WINHTTP-SERVER-API-Konfigurationsfehler meinerseits. Meine IP-Adresse hat sich geändert, und als ich ein neues Serverzertifikat auf dem Computer "MY" abgelegt habe, habe ich den ALREADY_EXISTS-Rückkehrcode für HttpSetServiceConfiguration ignoriert.

Daher habe ich ein früheres Server-TLS-Zertifikat verwendet, das den falschen allgemeinen Namen hatte und nicht mit meinem neuen Servernamen übereinstimmte.

Wenn Sie HttpDeleteServiceConfiguration () oder die Befehlszeile "netsh http delete sslcert 0.0.0.0:8443" nicht korrekt ausführen, wird ein böser Fehler mit den folgenden Symptomen angezeigt:

1) In TLS wird Ihr Client Hello sofort mit einem TCP-Paket von Ihrem Server empfangen, bei dem die Flag-Bits Ack und Reset gesetzt sind. (Ein Handshake-Fehler-Alarm, denke ich?)

2) Die Ereignisanzeige erhält "Die folgende schwerwiegende Warnung wurde generiert: 40. Der interne Fehlerstatus ist 107."

"Eine SSL 3.0-Verbindungsanforderung wurde von einer Remoteclientanwendung empfangen, aber keine der von der Clientanwendung unterstützten Cipher Suites wird vom Server unterstützt. Die SSL-Verbindungsanforderung ist fehlgeschlagen."

Vergewissern Sie sich vor dem Verfolgen einer nicht übereinstimmenden Cipher Suite, dass Sie wirklich das Serverzertifikat verwenden, mit dem Sie Folgendes verwenden möchten:

         netsh http show sslcert

und überprüfe die Hashwerte!

Dies könnte das Problem KeySpec = 2 - AT_SIGNATURE sein

certutil -verifystore -v Mein "Fingerabdruck von cert" zur Überprüfung des KeySpec-Werts. Wenn es 2 ist, müssen Sie das Zertifikat als PFX-Datei exportieren und dann certutil -importpfx AT_KEYEXCHANGE ausführen, um es zu reparieren.