¿Generar una CSR a través de IIS 7.5 en Windows Server 2008 R2 siempre crea una nueva clave privada?

Generando una CSR para un servidor Windows 2008 R2 y necesita asegurarse de que la clave privada utilizada para la CSR sea nueva.

He usado OpenSSL antes para crear mis propios certificados autofirmados para las pruebas y, si no recuerdo mal, pude especificar una clave privada para usar.

En los certificados del servidor IIS, nunca se me pide que genere ni elija una clave privada.

Entonces, ¿generar una CSR en un servidor basado en Windows siempre crea una nueva clave privada para él? Si no, ¿cómo me aseguro de que se haga / use una nueva clave privada?

si

El asistente "Crear solicitud de certificado" genera automáticamente un nuevo par de claves.

En los certificados del servidor IIS, nunca se me pide que genere ni elija una clave privada.

Esto en realidad no es cierto: el asistente simplemente no es muy obvio al respecto.

Cuando haya ingresado la información de identidad (Nombre común, Localidad, Organización, etc.) y presione "Siguiente", la segunda pantalla le pide 2 cosas:

1. Un proveedor de servicios criptográficos (CSP)
2. Un poco de longitud

Elegir el CSP predeterminado (el CSP de Microsoft RSA SChannel) y una longitud de bits de 2048 sería el equivalente de Windows a:

openssl req -new -newkey rsa:2048

Anatomía de una solicitud de firma

Se puede pensar que la CSR en sí misma tiene 3 "partes":

1. Información de identidad en texto claro (CN, Localidad, Org., Etc.)
   • Esto es simplemente cadenas, el firmante (CA) puede alterarlas a voluntad
2. La clave pública
   • Necesitará la clave privada correspondiente en su servidor
3. Campos opcionales de extensión
   • Todavía solo información clara del texto

El Emisor revisa la información en la solicitud de firma, y ​​puede alterar el contenido de ambos (1) y (3).
El Emisor luego usa su clave privada CA para encriptar la clave pública del solicitante (2).

Cuando se emite el Certificado final, contiene:

1. Información de identidad en texto claro (CN, Localidad, Org., Etc.)
   • Ahora con la información del emisor agregada
2. La clave pública
   • Sigue siendo el mismo que el anterior
3. Campos opcionales de extensión
   • Ahora quizás con los campos de extensión del emisor
4. Una gota de firma
   • Esta es la clave pública firmada con la clave privada de la CA

Ahora, la próxima vez que un cliente reciba su certificado, puede usar la clave pública de la CA emisora para descifrar el blob de firma (4) y compararlo con la clave pública del certificado