Всегда ли создание CSR через IIS 7.5 на Windows Server 2008 R2 создает новый закрытый ключ?

Создание CSR для сервера Windows 2008 R2 и необходимость убедиться, что закрытый ключ, используемый для CSR, является новым.

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

В сертификатах сервера IIS меня никогда не просят ни генерировать, ни выбирать закрытый ключ.

Итак, всегда ли создание CSR на сервере под управлением Windows создает для него новый закрытый ключ? Если нет, как я могу обеспечить создание / использование нового закрытого ключа?

да

Мастер «Создать запрос сертификата» автоматически генерирует новую пару ключей.

В сертификатах сервера IIS меня никогда не просят ни генерировать, ни выбирать закрытый ключ.

На самом деле это не так - волшебник просто не совсем уверен в этом.

Когда вы ввели идентификационную информацию (Общее имя, Местонахождение, Организация и т. Д.) И нажали «Далее», на втором экране запрашиваются 2 вещи:

1. Поставщик криптографических услуг (CSP)
2. Длина бит

Выбор CSP по умолчанию - Microsoft RSA SChannel CSP - и битовая длина 2048 будут для Windows эквивалентны:

openssl req -new -newkey rsa:2048

Анатомия подписывающего запроса

Сам CSR можно рассматривать как имеющий 3 "части":

1. Информация о личности в виде открытого текста (CN, Местность, Org. И т. Д.)
   • Это просто строки, подписавшая сторона (СА) может изменять их по своему желанию.
2. Открытый ключ
   • Вам понадобится соответствующий закрытый ключ на вашем сервере
3. Необязательные поля расширения
   • Все еще просто текстовая информация

Эмитент просматривает информацию в запросе на подпись, и может изменять содержание как (1), так и (3).
Затем Эмитент использует свой закрытый ключ CA для шифрования открытого ключа запрашивающих (2).

Когда выдается окончательный сертификат, он содержит:

1. Информация о личности в виде открытого текста (CN, Местность, Org. И т. Д.)
   • Теперь с информацией об эмитенте
2. Открытый ключ
   • Все тот же, что и выше
3. Необязательные поля расширения
   • Теперь возможно с полями расширения Эмитента
4. Подпись BLOB
   • Это открытый ключ, подписанный закрытым ключом CA

Теперь, когда клиент получит ваш сертификат в следующий раз, он может использовать открытый ключ ЦС эмитента для расшифровки объекта blob подписи (4) и сравнить его с открытым ключом в сертификате.