Назад | Перейти на главную страницу

Всегда ли при создании 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 можно представить как состоящую из трех частей:

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

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

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

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

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