Czy generowanie CSR za pomocą IIS 7.5 w systemie Windows Server 2008 R2 zawsze tworzy nowy klucz prywatny?

Generowanie CSR dla serwera Windows 2008 R2 i należy upewnić się, że klucz prywatny użyty do CSR jest nowy.

Używałem wcześniej OpenSSL do tworzenia własnych samopodpisanych certyfikatów do testowania i jeśli dobrze pamiętam, byłem w stanie określić klucz prywatny do użycia.

W certyfikatach serwera IIS nigdy nie jestem proszony o wygenerowanie lub wybranie klucza prywatnego.

Czy generowanie CSR na serwerze z systemem Windows zawsze tworzy dla niego nowy klucz prywatny? Jeśli nie, w jaki sposób mogę zapewnić, że nowy klucz prywatny zostanie utworzony / użyty?

tak

Kreator „Utwórz żądanie certyfikatu” automatycznie generuje nową parę kluczy.

W certyfikatach serwera IIS nigdy nie jestem proszony o wygenerowanie lub wybranie klucza prywatnego.

To w rzeczywistości nie jest prawdą - czarodziej po prostu nie jest w tym zbyt oczywisty.

Po wprowadzeniu informacji o tożsamości (nazwa zwyczajowa, miejscowość, organizacja itp.) I naciśnięciu przycisku „Dalej” na drugim ekranie zostaną wyświetlone 2 pytania:

1. Dostawca usług kryptograficznych (CSP)
2. Długość bitu

Wybór domyślnego CSP - Microsoft RSA SChannel CSP - i długość bitu 2048 byłaby odpowiednikiem systemu Windows:

openssl req -new -newkey rsa:2048

Anatomia wniosku o podpisanie

Sam CSR można uznać za składający się z 3 „części”:

1. Informacje o tożsamości w postaci zwykłego tekstu (CN, miejscowość, organizacja itp.)
   • To po prostu ciągi znaków, sygnatariusz (CA) może dowolnie je zmieniać
2. Klucz publiczny
   • Będziesz potrzebował odpowiedniego klucza prywatnego na swoim serwerze
3. Opcjonalne pola rozszerzeń
   • Nadal tylko jasne informacje tekstowe

Emitent sprawdza informacje zawarte we wniosku o podpisanie i może zmienić treść zarówno (1), jak i (3).
Następnie Emitent używa swojego prywatnego klucza CA do szyfrowania klucza publicznego żądającego (2).

Wydane końcowe świadectwo zawiera:

1. Informacje o tożsamości w postaci zwykłego tekstu (CN, miejscowość, organizacja itp.)
   • Teraz z dodanymi informacjami o wystawcy
2. Klucz publiczny
   • Nadal taki sam jak powyżej
3. Opcjonalne pola rozszerzeń
   • Teraz może z polami rozszerzeń wystawcy
4. Kropla sygnatury
   • Jest to klucz publiczny podpisany kluczem prywatnym urzędu certyfikacji

Teraz, gdy następnym razem klient dostanie twój certyfikat, może użyć klucza publicznego wystawcy CA do odszyfrowania obiektu blob podpisu (4) i porównania go z kluczem publicznym w certyfikacie