Por que o SSL Cipher-Suite do Windows fica restrito sob determinados certificados SSL?

Problema: o Windows Server 2008 R2 suportará apenas os seguintes conjuntos de criptografia ssl ao usar determinados certificados no servidor:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

Isso impede que os clientes XP se conectem ao servidor, pois a API criptográfica XP não suporta nenhuma cifra AES por padrão.
Como resultado, os seguintes erros aparecem nos logs do servidor ao tentar se conectar usando o Internet Explorer ou a área de trabalho remota. (já que eles usam o CAPI da microsoft)

Erro de Schannel 36874 "Uma conexão TLS 1.0 foi recebida de um aplicativo cliente remoto, mas alguns dos conjuntos de cifras suportados pelo cliente são suportados pelo servidor. A solicitação de conexão SSL falhou."
Erro de Schannel 36888 "O seguinte alerta fatal foi gerado: 40. O estado interno do erro é 1204"

Se o certificado usado no servidor foi gerado usando a opção Chave herdada no formulário de solicitação de certificado, a chave privada para esse certificado será armazenada na estrutura da API criptográfica herdada da Microsoft. Quando o servidor da Web tenta processar solicitações usando sua nova estrutura Cryptographic Next Generation (CNG), parece que algo relacionado à chave privada RSA armazenada na estrutura herdada não está disponível para a nova estrutura. Como resultado, o uso dos conjuntos de cifras RSA é severamente limitado.

Solução:
Gere a solicitação de certificado usando o modelo de chave CNG no assistente de solicitação de certificado personalizado.

MMC Gerenciador de certificados de computador local | Pasta Certificados pessoais | (clique direito) | Todas as tarefas -> Operações avançadas | Criar solicitação personalizada | "Prossiga sem política de inscrição" | selecione "(sem modelo) chave CNG" | prossiga para concluir a solicitação de certificado de acordo com suas necessidades.

Verificando se a chave está no lugar certo:
http://msdn.microsoft.com/en-us/library/bb204778(VS.85).aspx
http://www.jensign.com/KeyPal/index.html

Ferramentas para verificar conjuntos de cifras corretos:
http://pentestit.com/2010/05/16/ssltls-audit-audit-web-servers-ssl-ciphers/
https://www.ssllabs.com/

Configurações do conjunto de cifras 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-no-windows-vista.aspx

Levamos uma semana para descobrir. Espero que isso poupe a alguém o mesmo problema.

Eu mesmo tenho esse mesmo problema e este post me salvou uma tonelada de tempo, então obrigado a todos!

A solução de Gary está pronta, mas eu consegui resolver o problema simplesmente convertendo o PFX em PEM e depois novamente no PFX usando o openssl. O novo PFX importou o certificado no IIS da mesma forma, com a diferença de que posso ver as cifras ausentes.

É assim:

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

Em seguida, divida o arquivo cer em três, a chave, o certificado e o (s) certificado (s) intermediário (s)

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

Se você importar o novo arquivo .pfx para o IIS, ele usará todas as cifras que você espera ver.

Portanto, não há necessidade de reemitir o certificado.

Obrigado, sua postagem me ajudou, embora meu problema não fosse exatamente o mesmo.

No entanto, a causa foi um erro de configuração da API do WINHTTP SERVER da minha parte. Meu IP mudou e, quando coloquei um novo certificado de servidor na máquina "MY", ignorei o código de retorno ALREADY_EXISTS para HttpSetServiceConfiguration.

Portanto, usei um certificado TLS do servidor anterior que tinha o nome comum errado e não correspondia ao meu novo nome de servidor.

Se você não executar o HttpDeleteServiceConfiguration () ou a linha de comando "netsh http delete sslcert 0.0.0.0:8443" corretamente, você receberá um erro grave com estes sintomas:

1) No TLS, o seu Client Hello é recebido imediatamente com um pacote TCP do seu servidor com os bits de sinalizador Ack e Reset definidos. (Um alerta de falha de aperto de mão, eu acho?)

2) O visualizador de eventos obtém "O seguinte alerta fatal foi gerado: 40. O estado de erro interno é 107".

"Uma solicitação de conexão SSL 3.0 foi recebida de um aplicativo cliente remoto, mas nenhum dos conjuntos de cifras suportados pelo aplicativo cliente é suportado pelo servidor. A solicitação de conexão SSL falhou."

Portanto, antes de procurar uma incompatibilidade do conjunto de criptografia, verifique se realmente está usando o certificado do servidor com o qual deseja usar:

         netsh http show sslcert

e verifique os valores de hash!

Este pode ser o problema KeySpec = 2 - AT_SIGNATURE

certutil -verifystore -v Minha "Impressão digital do certificado" para verificar o valor KeySpec. Se for 2, você precisará exportar o certificado como um arquivo PFX e, em seguida, execute certutil -importpfx AT_KEYEXCHANGE para corrigi-lo.