A geração de um CSR por meio do IIS 7.5 no Windows Server 2008 R2 sempre cria uma nova chave privada?

A geração de um CSR para um servidor Windows 2008 R2 e a necessidade de garantir que a chave privada usada para o CSR seja nova.

Eu usei o OpenSSL antes para criar meus próprios certificados autoassinados para teste e, se bem me lembro, consegui especificar uma chave privada a ser usada.

Nos Certificados do servidor IIS, nunca sou solicitado a gerar nem escolher uma chave privada.

Então, gerar um CSR em um servidor baseado no Windows sempre cria uma nova chave privada para ele? Caso contrário, como posso garantir / criar uma nova chave privada?

sim

O assistente "Criar solicitação de certificado" gera automaticamente um novo par de chaves.

Nos Certificados do servidor IIS, nunca sou solicitado a gerar nem escolher uma chave privada.

Na verdade, isso não é verdade - o assistente simplesmente não é super óbvio.

Quando você digita as informações de identidade (Nome Comum, Localidade, Organização etc.) e clica em "Avançar", a segunda tela pede duas coisas:

1. Um provedor de serviços criptográficos (CSP)
2. Um comprimento de bit

Escolher o CSP padrão - o Microsoft RSA SChannel CSP - e um Bit Length de 2048 seria o equivalente do Windows a:

openssl req -new -newkey rsa:2048

Anatomia de uma solicitação de assinatura

O próprio CSR pode ser considerado como tendo 3 "partes":

1. Informações de identidade em texto não criptografado (CN, localidade, organização etc.)
   • Isso é simplesmente uma sequência, o signatário (a CA) pode alterar aqueles à vontade
2. A chave pública
   • Você precisará da chave privada correspondente no seu servidor
3. Campos de extensão opcionais
   • Ainda, apenas apague as informações de texto

O Emissor analisa as informações na solicitação de assinatura e pode alterar o conteúdo de (1) e (3).
O emissor usa sua chave privada da CA para criptografar a chave pública do solicitante (2).

Quando o certificado final é emitido, ele contém:

1. Informações de identidade em texto não criptografado (CN, localidade, organização etc.)
   • Agora com as informações do emissor adicionadas
2. A chave pública
   • Ainda o mesmo que acima
3. Campos de extensão opcionais
   • Agora talvez com campos de extensão do emissor
4. Um blob de assinatura
   • Essa é a chave pública assinada com a chave privada da CA

Agora, na próxima vez que um cliente receber seu certificado, ele poderá usar a chave pública da CA do emissor para descriptografar o blob de assinatura (4) e compará-lo com a chave pública no certificado.