Erstellt das Generieren einer CSR über IIS 7.5 unter Windows Server 2008 R2 immer einen neuen privaten Schlüssel?

Generieren einer CSR für einen Windows 2008 R2-Server und Sicherstellen, dass der für die CSR verwendete private Schlüssel neu ist.

Ich habe OpenSSL bereits verwendet, um meine eigenen selbstsignierten Zertifikate zum Testen zu erstellen. Wenn ich mich richtig erinnere, konnte ich einen privaten Schlüssel angeben, der verwendet werden soll.

In IIS-Serverzertifikaten werde ich niemals aufgefordert, einen privaten Schlüssel zu generieren oder auszuwählen.

Erstellt das Generieren einer CSR auf einem Windows-basierten Server immer einen neuen privaten Schlüssel dafür? Wenn nicht, wie stelle ich sicher, dass ein neuer privater Schlüssel erstellt / verwendet wird?

Ja

Der Assistent "Zertifikatanforderung erstellen" generiert automatisch ein neues Schlüsselpaar.

In IIS-Serverzertifikaten werde ich niemals aufgefordert, einen privaten Schlüssel zu generieren oder auszuwählen.

Dies ist eigentlich nicht wahr - der Assistent ist einfach nicht sehr offensichtlich.

Wenn Sie die Identitätsinformationen (allgemeiner Name, Ort, Organisation usw.) eingegeben und auf "Weiter" geklickt haben, werden im zweiten Bildschirm zwei Dinge abgefragt:

1. Ein Cryptographic Service Provider (CSP)
2. Eine Bitlänge

Die Auswahl des Standard-CSP - des Microsoft RSA SChannel CSP - und einer Bitlänge von 2048 entspricht Windows:

openssl req -new -newkey rsa:2048

Anatomie einer Unterzeichnungsanfrage

Der CSR selbst besteht aus 3 "Teilen":

1. Identitätsinformationen im Klartext (CN, Lokalität, Organisation usw.)
   • Dies sind einfach Zeichenfolgen, die der Unterzeichner (die Zertifizierungsstelle) nach Belieben ändern kann
2. Der öffentliche Schlüssel
   • Sie benötigen den entsprechenden privaten Schlüssel auf Ihrem Server
3. Optionale Erweiterungsfelder
   • Immer noch nur Klartextinformationen

Die Emittentin prüft die Informationen in der Unterzeichnungsanforderung und kann den Inhalt von (1) und (3) ändern.
Der Aussteller verwendet dann seinen privaten CA- Schlüssel , um den öffentlichen Schlüssel des Anforderers zu verschlüsseln (2).

Wenn das endgültige Zertifikat ausgestellt wird, enthält es:

1. Identitätsinformationen im Klartext (CN, Lokalität, Organisation usw.)
   • Jetzt mit Emittenteninformationen hinzugefügt
2. Der öffentliche Schlüssel
   • Immer noch das gleiche wie oben
3. Optionale Erweiterungsfelder
   • Jetzt vielleicht mit Ausstellererweiterungsfeldern
4. Ein Signatur-Blob
   • Dies ist der öffentliche Schlüssel, der mit dem privaten Schlüssel der Zertifizierungsstelle signiert ist

Das nächste Mal der Emittentin CA ein Client erhalten hat Ihr Zertifikat präsentiert, kann es verwenden nun die öffentlichen Schlüssel die Signatur Blob (4) und vergleicht sie mit dem öffentlichen Schlüssel im Zertifikat zu entschlüsseln