Чи створює КСВ через IIS 7.5 на Windows Server 2008 R2 завжди створюється новий приватний ключ?

Створення CSR для сервера Windows 2008 R2 та потрібно переконатися, що приватний ключ, що використовується для CSR, новий.

Раніше я використовував OpenSSL, щоб створити власні сертифіковані сертифікати для тестування, і якщо я пам'ятаю правильно, мені вдалося вказати приватний ключ для використання.

У сертифікатах сервера IIS мене ніколи не просять генерувати або вибирати приватний ключ.

Отже, чи генерування CSR на сервері на базі Windows завжди створює новий приватний ключ для нього? Якщо ні, то як я можу зробити новий приватний ключ зроблений / використаний?

Так

Майстер "Створення запиту на сертифікат" автоматично генерує нову пару ключів.

У сертифікатах сервера IIS мене ніколи не просять генерувати або вибирати приватний ключ.

Це насправді не так - майстер просто не надто очевидний.

Коли ви ввели інформацію про особу (Загальна назва, Місцезнаходження, Організація тощо) та натисніть "Далі", на другому екрані з'являються дві речі:

1. Криптографічний постачальник послуг (CSP)
2. Біт-довжина

Вибір CSP за замовчуванням - CSP для Microsoft RSA SChannel - і довжина бітів 2048 року буде еквівалентом Windows:

openssl req -new -newkey rsa:2048

Анатомія запиту на підпис

Саму КСВ можна вважати такою, що має 3 "частини":

1. Інформація про особу в чіткому тексті (CN, місцеперебування, організація тощо)
   • Це просто рядки, підписав (CA) може змінити це за бажанням
2. Публічний ключ
   • Вам знадобиться відповідний приватний ключ на вашому сервері
3. Необов’язкові поля розширення
   • Ще просто зрозуміла текстова інформація

Емітент переглядає інформацію в запиті на підписання, може змінювати вміст як (1), так і (3).
Потім Емітент використовує свій приватний ключ CA для шифрування відкритого ключа запитувачів (2).

Коли видається остаточний сертифікат, він містить:

1. Інформація про особу в чіткому тексті (CN, місцеперебування, організація тощо)
   • Тепер додано інформацію про емітента
2. Публічний ключ
   • Ще те саме, що вище
3. Необов’язкові поля розширення
   • Тепер, можливо, з полями розширень видавця
4. Підпис краплі
   • Це Відкритий ключ, підписаний приватним ключем CA

Тепер, коли наступний раз клієнт отримає ваш сертифікат, він може використовувати відкритий ключ CA емітента для розшифрування блоку підписів (4) та порівняння його з відкритим ключем у сертифікаті