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

Question

Gerando um CSR para um servidor Windows 2008 R2 e precisa garantir que a chave privada usada para o CSR seja nova.

Eu usei o OpenSSL antes para criar meus próprios certificados auto-assinados para teste e, se bem me lembro, consegui especificar uma chave privada para usar.

Nos Certificados do Servidor IIS, nunca me pedem para gerar nem escolher uma chave privada.

Então, gerar um CSR em um servidor baseado em Windows sempre cria uma nova chave privada para ele? Se não, como asseguro que uma nova chave privada seja feita / usada?

    

Answer 1

Sim

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

In IIS Server Certificates, I am never asked to generate nor pick a private key.

Isso não é verdade - o assistente não é tão óbvio quanto a isso.

Quando você inserir as informações de identidade (Nome comum, Localidade, Organização, etc.) e clicar em "Avançar", a segunda tela perguntará por duas coisas:

1. Um provedor de serviços de criptografia (CSP)
2. Um comprimento de bit

EscolheroCSPpadrão-oMicrosoftRSASChannelCSP-eumBitLengthde2048seriaoequivalentedoWindowsa:

opensslreq-new-newkeyrsa:2048

Anatomiadeumasolicitaçãodeassinatura

OpróprioCSRpodeserconsideradocomotendo3"partes":

1. Informações de identidade em texto não criptografado (CN, Localidade, Org. etc.)
   • Isto é simplesmente strings, o signatário (o CA) pode alterar aqueles à vontade
2. A chave pública
   • Você precisará da chave privada correspondente em seu servidor
3. campos de ampliação opcionais
   • Ainda apenas limpar as informações de texto

O Emissor revisa as informações no pedido de assinatura, podendo alterar o conteúdo de ambos (1) e (3).
O Emissor então usa sua chave privada para criptografar a chave pública dos solicitantes (2).

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

1. Informações de identidade em texto não criptografado (CN, Localidade, Org. etc.)
   • Agora com as informações do emissor adicionadas
2. A chave pública
   • Ainda é o mesmo que acima
3. campos de ampliação opcionais
   • Agora, talvez com campos de extensão do emissor
4. Um blob de assinatura
   • Esta é 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 à chave pública no certificado