Perché la suite di crittografia SSL di Windows è soggetta a determinati certificati SSL?

Problema: Windows Server 2008 R2 supporterà solo le seguenti suite di crittografia SSL quando si utilizzano determinati certificati sul server:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

Ciò impedisce ai client XP di connettersi al server poiché l'API crittografica XP non supporta alcun codice AES per impostazione predefinita.
Di conseguenza, i seguenti errori compaiono nei registri del server quando si tenta di connettersi utilizzando Internet Explorer o il desktop remoto. (dal momento che usano CAPI di microsoft)

Errore Schannel 36874 "È stata ricevuta una connessione TLS 1.0 da un'applicazione client remota, ma una parte delle suite di crittografia supportate dal client sono supportate dal server. La richiesta di connessione SSL non è riuscita."
Schannel Error 36888 "È stato generato il seguente avviso irreversibile: 40. Lo stato di errore interno è 1204"

Se il certificato utilizzato sul server è stato generato utilizzando l'opzione Chiave legacy nel modulo di richiesta certificato, la chiave privata per quel certificato verrà archiviata nel framework API crittografico legacy di Microsoft. Quando il server Web tenta di elaborare le richieste utilizzando il suo nuovo framework CNG (Cryptographic Next Generation), sembra che qualcosa correlato alla chiave privata RSA memorizzata nel framework legacy non sia disponibile per il nuovo framework. Di conseguenza, l'uso delle suite di crittografia RSA è fortemente limitato.

Soluzione:
generare la richiesta di certificato utilizzando il modello chiave CNG nella procedura guidata di richiesta certificati personalizzata.

MMC | Gestione certificati computer locale Cartella dei certificati personali | (tasto destro) | Tutte le attività -> Operazioni avanzate | Crea richiesta personalizzata | "Procedi senza politica di iscrizione" | seleziona "(nessun modello) chiave CNG" | procedere per completare la richiesta di certificato in base alle proprie esigenze.

Verifica che la chiave sia nel posto giusto:
http://msdn.microsoft.com/en-us/library/bb204778(VS.85).aspx
http://www.jensign.com/KeyPal/index.html

Strumenti per la verifica delle suite di crittografia corrette:
http://pentestit.com/2010/05/16/ssltls-audit-audit-web-servers-ssl-ciphers/
https://www.ssllabs.com/

Impostazioni della suite di crittografia 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-on-Windows-vista.aspx

Ci è voluta una settimana per capire. Spero che questo salvi a qualcuno lo stesso problema.

Ho avuto questo stesso identico problema e questo post mi ha fatto risparmiare un sacco di tempo, quindi grazie a tutti!

La soluzione di Gary è perfetta ma sono riuscito a risolvere il problema semplicemente convertendo il PFX in PEM e poi di nuovo in PFX usando openssl. Il nuovo PFX ha importato il certificato in IIS allo stesso modo con la differenza che posso vedere le cifre mancanti.

Questo è come:

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

Quindi dividere il file cer in tre, la chiave, il certificato e il certificato intermedio [s]

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

Quindi, se importi il ​​nuovo file .pfx in IIS, utilizzerà tutte le cifre che ti aspetti di vedere.

Quindi non è necessario riemettere il certificato.

Grazie, il tuo post mi ha aiutato, anche se il mio problema non era esattamente lo stesso.

Tuttavia, la causa è stata un errore di configurazione dell'API del SERVER WINHTTP da parte mia. Il mio IP è cambiato e quando ho inserito un nuovo certificato server nella macchina "MY", ho ignorato il codice di ritorno ALREADY_EXISTS per HttpSetServiceConfiguration.

Quindi ho usato un precedente certificato TLS del server che aveva il nome comune sbagliato e non corrispondeva al mio nuovo nome del server.

Se non esegui correttamente HttpDeleteServiceConfiguration () o la riga di comando "netsh http delete sslcert 0.0.0.0:8443" otterrai un brutto errore con questi sintomi:

1) In TLS, Client Hello riceve immediatamente un pacchetto TCP dal server con i bit flag Ack e Reset impostati. (Penso che un avviso di fallimento della stretta di mano?)

2) Il visualizzatore eventi ottiene "È stato generato il seguente avviso irreversibile: 40. Lo stato di errore interno è 107."

"È stata ricevuta una richiesta di connessione SSL 3.0 da un'applicazione client remota, ma nessuna delle suite di crittografia supportate dall'applicazione client è supportata dal server. La richiesta di connessione SSL non è riuscita."

Quindi, prima di andare a caccia di una mancata corrispondenza della suite di crittografia, assicurati di utilizzare davvero il certificato del server che desideri utilizzare con:

         netsh http show sslcert

e controlla i valori di hash!

Questo potrebbe essere il problema KeySpec = 2 - AT_SIGNATURE

certutil -verifystore -v Il mio "Identificazione personale di cert" per verificare il valore KeySpec. Se è 2, dovrai esportare il certificato come file PFX e quindi eseguire certutil -importpfx AT_KEYEXCHANGE per correggerlo.