Generare un CSR tramite IIS 7.5 su Windows Server 2008 R2 crea sempre una nuova chiave privata?


11

Generazione di un CSR per un server Windows 2008 R2 e necessità di garantire che la chiave privata utilizzata per il CSR sia nuova.

Ho usato OpenSSL prima di creare i miei certificati autofirmati per i test e, se ricordo bene, sono stato in grado di specificare una chiave privata da utilizzare.

Nei certificati server IIS, non mi viene mai chiesto di generare né scegliere una chiave privata.

Quindi, generare un CSR su un server basato su Windows crea sempre una nuova chiave privata per esso? In caso contrario, come posso garantire che venga creata / utilizzata una nuova chiave privata?


1
Intendi la chiave privata ?
EEAA

1
Sì, grazie, modifica ora. Sono uno sviluppatore prima di un amministratore di sistema, quindi la chiave primaria mi è uscita per prima. :)
jzimmerman2011

Generare un CSR o generare un certificato? Che cosa stai facendo esattamente e come lo stai facendo? (Fa la differenza.)
HopelessN00b

Sto generando un CSR che verrà dato a una CA per creare il certificato. Questo viene fatto tramite IIS e la sua interfaccia Certificati server.
jzimmerman2011,

Risposte:


8

La procedura guidata "Crea richiesta certificato" genera automaticamente una nuova coppia di chiavi.

Nei certificati server IIS, non mi viene mai chiesto di generare né scegliere una chiave privata.

Questo in realtà non è vero - il mago non è super ovvio.

Dopo aver inserito le informazioni sull'identità (nome comune, località, organizzazione ecc.) E aver premuto "Avanti", la seconda schermata richiede 2 cose:

  1. Un provider di servizi crittografici (CSP)
  2. Una lunghezza di bit

inserisci qui la descrizione dell'immagine

La scelta del CSP predefinito, il CSP Microsoft RSA SChannel, e una lunghezza in bit di 2048 equivarrebbe a Windows equivalente a:

openssl req -new -newkey rsa:2048

Anatomia di una richiesta di firma

Si può pensare che il CSR stesso abbia 3 "parti":

  1. Informazioni sull'identità in chiaro (CN, località, organizzazione ecc.)
    • Si tratta semplicemente di stringhe, il firmatario (la CA) può modificare quelle a volontà
  2. La chiave pubblica
    • Avrai bisogno della chiave privata corrispondente sul tuo server
  3. Campi di estensione opzionali
    • Ancora solo chiare informazioni di testo

L'Emittente esamina le informazioni nella richiesta di firma e può modificare il contenuto di entrambi (1) e (3).
L'Emittente utilizza quindi la sua chiave privata CA per crittografare la chiave pubblica dei richiedenti (2).

Quando viene rilasciato il Certificato finale, contiene:

  1. Informazioni sull'identità in chiaro (CN, località, organizzazione ecc.)
    • Ora con le informazioni sull'emittente aggiunte
  2. La chiave pubblica
    • Sempre come sopra
  3. Campi di estensione opzionali
    • Ora forse con i campi di estensione dell'Emittente
  4. Un blob di firma
    • Questa è la chiave pubblica firmata con la chiave privata della CA.

Ora, la volta successiva che un client riceve il certificato, può utilizzare la chiave pubblica della CA dell'emittente per decrittografare il BLOB di firma (4) e confrontarlo con la chiave pubblica nel certificato

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.