¿Por qué se restringe SSL Cipher-Suite de Windows bajo ciertos certificados SSL?

Problema: Windows Server 2008 R2 solo admitirá los siguientes conjuntos de cifrado SSL cuando se utilizan ciertos certificados en el servidor:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

Esto evita que los clientes de XP se conecten al servidor ya que la API criptográfica de XP no admite ningún cifrado AES de forma predeterminada.
Como resultado, los siguientes errores aparecen en los registros del servidor al intentar conectarse mediante Internet Explorer o el escritorio remoto. (ya que usan el CAPI de microsoft)

Error de Schannel 36874 "Se recibió una conexión TLS 1.0 de una aplicación cliente remota, pero el servidor admite las suites de cifrado admitidas por el cliente. La solicitud de conexión SSL ha fallado".
Error de Schannel 36888 "Se generó la siguiente alerta fatal: 40. El estado de error interno es 1204"

Si el certificado que se usa en el servidor se generó utilizando la opción Clave heredada en el formulario de solicitud de certificado, la clave privada para ese certificado se almacenará en el marco de la API criptográfica heredada de Microsoft. Cuando el servidor web intenta procesar las solicitudes utilizando su nuevo marco de trabajo Cryptographic Next Generation (CNG), parece que algo relacionado con la clave privada RSA almacenada en el marco heredado no está disponible para el nuevo marco. Como resultado, el uso de los conjuntos de cifrado RSA está muy limitado.

Solución:
genere la solicitud de certificado utilizando la plantilla de clave CNG en el asistente de solicitud de certificado personalizado.

MMC | Gerente de Certificado de Computadora Local | Carpeta de certificados personales | (clic derecho) | Todas las tareas -> Operaciones avanzadas | Crear solicitud personalizada | "Continuar sin política de inscripción" | seleccione "(sin plantilla) clave CNG" | proceda a completar la solicitud de certificado según sus necesidades

Verificando que la clave esté en el lugar correcto:
http://msdn.microsoft.com/en-us/library/bb204778(VS.85).aspx
http://www.jensign.com/KeyPal/index.html

Herramientas para verificar los conjuntos de cifrado correctos:
http://pentestit.com/2010/05/16/ssltls-audit-audit-web-servers-ssl-ciphers/
https://www.ssllabs.com/

Configuración del conjunto de cifrado SSL:
http://support.microsoft.com/kb/245030
http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order -en-internet-explorer-7-on-windows-vista.aspx

Esto nos tomó una semana para darnos cuenta. Espero que esto le ahorre a alguien el mismo problema.

Tengo este mismo problema y esta publicación me ahorró un montón de tiempo, así que gracias a todos.

La solución de Gary es acertada, pero logré resolver el problema simplemente convirtiendo el PFX a PEM y luego nuevamente a PFX nuevamente usando openssl. El nuevo PFX importó el certificado en IIS de la misma manera con la diferencia de que puedo ver los cifrados que faltan.

Así es como:

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

Luego divida el archivo cer en tres, la clave, el certificado y el certificado intermedio [s]

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

Luego, si importa el nuevo archivo .pfx a IIS, usará todos los cifrados que espera ver.

Por lo tanto, no es necesario volver a emitir el certificado.

Gracias, tu publicación me ayudó, aunque mi problema no era exactamente el mismo.

Sin embargo, la causa fue un error de configuración de la API del SERVIDOR WINHTTP de mi parte. Mi IP cambió, y cuando puse un nuevo certificado de servidor en la máquina "MI", ignoré el código de retorno ALREADY_EXISTS para HttpSetServiceConfiguration.

Entonces utilicé un certificado TLS del servidor anterior que tenía un nombre común incorrecto y no coincidía con el nombre de mi nuevo servidor.

Si no realiza HttpDeleteServiceConfiguration () o la línea de comando "netsh http delete sslcert 0.0.0.0:8443" correctamente, obtendrá un error desagradable con estos síntomas:

1) En TLS, su saludo de cliente se encuentra inmediatamente con un paquete TCP de su servidor con los bits de marca Ack y Reset establecidos. (¿Creo que una alerta de falla de apretón de manos?)

2) El visor de eventos obtiene "Se generó la siguiente alerta fatal: 40. El estado de error interno es 107".

"Se recibió una solicitud de conexión SSL 3.0 de una aplicación cliente remota, pero ninguno de los conjuntos de cifrado admitidos por la aplicación cliente son compatibles con el servidor. La solicitud de conexión SSL ha fallado".

Por lo tanto, antes de perseguir una incompatibilidad de conjunto de cifrado, asegúrese de que realmente esté utilizando el certificado de servidor que desea utilizar con:

         netsh http show sslcert

y verifique los valores hash!

Este podría ser el problema KeySpec = 2 - AT_SIGNATURE

certutil -verifystore -v Mi "Huella digital de cert" para verificar el valor de KeySpec. Si es 2, deberá exportar el certificado como un archivo PFX y luego ejecutar certutil -importpfx AT_KEYEXCHANGE para solucionarlo.