Как сгенерировать CSR для сертификата подписи кода через MMC

Оснастка «Сертификаты» в консоли управления Microsoft Management Console (MMC) позволяет создать запрос на сертификат PKCS #10 на компьютере с Windows без установки дополнительного программного обеспечения. Это руководство разбирает данный мастер по экранам для сертификата подписи кода, и начинается оно с того, что часто пропускают в старых инструкциях: правила для приватных ключей подписи кода изменились 1 июня 2023 года, и именно они определяют, годится ли запрос, созданный через MMC, вообще.

Прочтите это требование, прежде чем открывать мастер. Остальная часть руководства предполагает, что вы уже знаете, какой путь выберет ваш заказ.

Ключи подписи кода должны создаваться на аппаратном устройстве

Согласно базовым требованиям CA/Browser Forum к подписи кода, вступившим в силу 1 июня 2023 года, приватный ключ каждого публично доверенного сертификата подписи кода должен создаваться, храниться и использоваться в аппаратном криптомодуле, сертифицированном как минимум по FIPS 140-2 Level 2, Common Criteria EAL 4+ или эквивалентному стандарту. Это касается как стандартных сертификатов (Organization Validation и Individual Validation), так и Extended Validation. Для EV-сертификатов подписи кода это уже действовало; изменение 2023 года распространило то же правило и на стандартные продукты.

Требования также фиксируют параметры самого ключа. Ключи RSA должны быть не менее 3072 бит, ключи ECDSA должны использовать кривые NIST P-256, P-384 или P-521, а SHA-1 не допускается для сертификатов подписи кода.

Не менее важно и то, что удостоверяющий центр обязан доказать, что ключ действительно находится в аппаратном устройстве, используя один из методов, перечисленных в требованиях. На практике вам встретятся следующие:

• CA присылает вам аппаратный токен, на котором уже находится пара ключей, сгенерированная CA на этом устройстве.
• Вы подписываете запрос сертификатом производителя, что и означает аттестацию ключа: доказательство того, что ключ был создан неэкспортируемым способом внутри соответствующего требованиям устройства.
• Вы используете комбинацию криптобиблиотеки и аппаратного модуля, предписанную CA.
• Вы предоставляете отчёт IT-аудита, отчёт от службы защиты ключей в облаке или соглашение, которое вы подписываете через соответствующую требованиям службу подписи.

Ни одному из этих условий не удовлетворяет запрос, который MMC создаёт с использованием Microsoft Software Key Storage Provider. Этот провайдер создаёт ключ в программном хранилище Windows, поэтому итоговый запрос будет отклонён для публично доверенного сертификата подписи кода независимо от того, как заполнены остальные шаги мастера. Удостоверяющие центры также одновременно прекратили предлагать генерацию ключей через браузер и доставку загружаемого файла .pfx для этих продуктов.

Если ваша цель — публично доверенный сертификат, путь определяется уже при оформлении заказа. Либо CA генерирует ключ на токене и отправляет его вам по почте, и в этом случае вам не нужно создавать CSR, либо вы генерируете ключ на уже имеющемся у вас аппаратном устройстве и отправляете аттестацию вместе с запросом. Руководство методы доставки сертификата подписи кода сравнивает оба варианта, а пошаговые инструкции для конкретных устройств здесь:

• YubiKey 5 FIPS: генерация CSR и аттестация
• Luna Network Attached HSM v7.x: руководство по CSR и аттестации

Где MMC всё ещё уместен

Мастер не устарел. Именно выбранный внутри него провайдер определяет, где рождается ключ, и есть три ситуации, в которых он остаётся подходящим инструментом.

Запрос, обеспеченный аппаратным провайдером. Список Cryptographic Service Provider в мастере показывает все провайдеры, установленные на машине, а не только программные от Microsoft. Как только установлен драйвер токена или минидрайвер смарт-карты, его провайдер также появляется в этом списке. Разница в том, где рождается пара ключей: программный провайдер создаёт её на вашем компьютере, тогда как аппаратный провайдер, например провайдер смарт-карты или токена, поручает генерацию пары самому устройству, которое затем хранит приватный ключ и контролирует доступ к нему. Выбрав аппаратный провайдер, вы получите от MMC запрос для ключа, который никогда не существовал в программном виде.

Прежде чем полагаться на это, учтите два момента. MMC создаёт запрос PKCS #10 и ничего больше, поэтому он не генерирует файл аттестации ключа, который большинство удостоверяющих центров хотят получить вместе с ним. Такой файл создаётся собственными инструментами устройства. И именно CA решает, какой метод подтверждения он примет, причём многие предписывают использовать для этого свою собственную утилиту. Уточните у своего CA, какой путь он поддерживает, прежде чем что-либо генерировать, потому что ключ, созданный не тем инструментом, впоследствии перенести нельзя.

Внутренний или корпоративный CA. Базовые требования регулируют публично доверенные сертификаты. Сертификат, выданный вашим собственным CA на базе Active Directory Certificate Services для внутренней подписи, находится за пределами этой сферы, поэтому ваша собственная политика определяет, как хранится ключ, и программный провайдер здесь является законным выбором. Помните, что вы получаете: код, подписанный таким образом, будет доверенным только на машинах, которые уже доверяют вашему внутреннему корневому сертификату, а повсюду ещё Windows будет считать издателя неизвестным.

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

Шаг 1: Откройте оснастку «Сертификаты»

Нажмите клавишу Windows + R, введите mmc и нажмите Enter. Также можно ввести mmc в поле поиска на панели задач и открыть оттуда. Подтвердите запрос контроля учётных записей. Откроется пустое окно Console1.

Нажмите Файл, затем Добавить или удалить оснастку. В списке Доступные оснастки выберите Сертификаты и нажмите Добавить.

Windows теперь спросит, каким хранилищем сертификатов должна управлять оснастка: Моя учётная запись пользователя, Учётная запись службы или Учётная запись компьютера. Этот выбор важнее для сертификата подписи кода, чем для сертификата веб-сервера, поскольку он определяет, где будет находиться ключ и в каком хранилище будет искать ваш инструмент подписи:

• Моя учётная запись пользователя помещает ключ в личное хранилище вошедшего в систему пользователя. Это обычный выбор, когда разработчик подписывает интерактивно, поскольку signtool от Microsoft по умолчанию открывает хранилище My текущего пользователя.
• Учётная запись компьютера помещает ключ в хранилище компьютера, что подходит для сервера сборки, где подпись выполняется под учётной записью службы. Инструментам подписи нужно указать искать там: signtool принимает ключ /sm для хранилища компьютера.

Если вы выбираете Моя учётная запись пользователя, нажмите Готово. Если выбираете Учётная запись компьютера, нажмите Далее, оставьте выбранным Локальный компьютер (компьютер, на котором выполняется эта консоль) и нажмите Готово. В любом случае нажмите ОК, чтобы закрыть окно Добавление и удаление оснасток.

Два ярлыка полностью пропускают этап с оснасткой, когда вам не нужна сохранённая консоль: certmgr.msc открывает хранилища сертификатов текущего пользователя напрямую, а certlm.msc открывает хранилища локального компьютера. Если вы вручную создали консоль и планируете вернуться к ней позже, используйте Файл, затем Сохранить, чтобы сохранить её.

Шаг 2: Начните создание настраиваемого запроса

В дереве консоли разверните Сертификаты и щёлкните правой кнопкой мыши по папке Личное (или по папке Сертификаты под ней, если хранилище уже содержит сертификаты). Выберите Все задачи, затем Дополнительные операции, затем Создать настраиваемый запрос. Те же команды находятся в меню Действие, если вы предпочитаете этот способ.

Откроется мастер Регистрация сертификатов на экране Прежде чем начать. Нажмите Далее.

На экране Выбор политики регистрации сертификатов найдите раздел Настраиваемый запрос и выберите Продолжить без политики регистрации, затем нажмите Далее. Это указывает Windows создать автономный запрос для внешнего CA вместо регистрации по шаблону Active Directory.

На странице Настраиваемый запрос есть три параметра:

• Шаблон. Выберите (Нет шаблона) Ключ CNG. Это использует Key Storage Provider — именно так регистрируются современные аппаратные провайдеры. (Нет шаблона) Устаревший ключ использует старые провайдеры CryptoAPI и нужен только тогда, когда конкретное устройство или приложение этого требует.
• Не включать расширения по умолчанию. Оставьте флажок снятым, если только вы не собираетесь отправлять только те расширения, которые задали вручную.
• Формат запроса. Выберите PKCS #10. Его принимают все CA. CMC предназначен для запросов, ориентированных на системы, которые специально его требуют.

Нажмите Далее. На странице Сведения о сертификате вы увидите одну строку с надписью Настраиваемый запрос и статусом Доступно. Нажмите стрелку Сведения справа от этой строки, чтобы развернуть её, затем нажмите появившуюся кнопку Свойства. Откроется диалог Свойства сертификата с четырьмя вкладками: Общие, Субъект, Расширения и Закрытый ключ.

Шаг 3: Введите данные субъекта

На вкладке Общие введите Понятное имя и, при желании, Описание. Оба поля являются локальными метками, которые помогают позже найти сертификат в хранилище. Ни одно из них не входит в запрос и не проверяется.

Перейдите на вкладку Субъект. Здесь собирается идентификационная информация, которая будет отображаться как издатель программного обеспечения. В разделе Имя субъекта выберите пункт из раскрывающегося списка Тип, введите соответствующий текст в поле Значение и нажмите Добавить >. Каждая запись переходит в список справа, где Windows отображает её в сокращённом виде (CN=, O=, OU=, L=, S=, C=). Повторите для каждого из следующих пунктов:

• Общее имя (CN): зарегистрированное название вашей организации или полное юридическое имя физического лица для индивидуального сертификата. Это идентификатор, который видят пользователи, когда Windows называет издателя.
• Организация (O): зарегистрированное название организации, которой принадлежит сертификат. Если название содержит символ, например амперсанд, напишите его словами или уберите, поскольку такие символы не принимаются в этом поле. «AB & C Corporation» превращается в «AB and C Corporation» или «ABC Corporation».
• Подразделение (OU): отдел, занимающийся оформлением заявки, например IT. Необязательно.
• Населённый пункт (L): город, в котором зарегистрирована организация.
• Область/штат (S): область или штат, записанные полностью. Используйте «Флорида», а не «FL».
• Страна (C): двухбуквенный код страны ISO для места, где зарегистрирована организация, например US.

Введите данные, которые точно совпадают с вашими юридическими записями, поскольку CA проверяет их по публичным и официальным источникам перед выпуском сертификата. Несоответствие — самая частая причина, по которой заказ сертификата подписи кода застревает на этапе проверки.

Оставьте поле Альтернативное имя пустым. Альтернативные имена субъекта (SAN) идентифицируют серверы по имени узла, а сертификат подписи кода идентифицирует издателя, а не машину, поэтому он не содержит DNS-записей.

Шаг 4: Выберите провайдера, размер ключа и хеш

Откройте вкладку Закрытый ключ. Она содержит несколько сворачиваемых групп: Поставщик служб криптографии, Параметры ключа, Выбор алгоритма хеширования, Выбор формата подписи и Разрешения ключа. Щёлкните по заголовку, чтобы развернуть его.

Сначала разверните Поставщик служб криптографии, поскольку именно этот параметр затрагивают базовые требования. Список показывает все провайдеры, установленные на машине, с флажком у каждого. Убедитесь, что отмечен только тот провайдер, который вам действительно нужен:

• Для публично доверенного сертификата подписи кода выберите провайдер, принадлежащий вашему токену или HSM. Он появляется в этом списке только после установки драйвера или минидрайвера устройства, поэтому сначала подключите устройство и установите его программное обеспечение.
• RSA, Microsoft Software Key Storage Provider — это программный вариант. Используйте его только для внутреннего CA или тестового сертификата.
• В списке также есть записи ECDSA, такие как ECDSA_P256, Microsoft Software Key Storage Provider. Прежде чем выбрать этот вариант, убедитесь, что ваш CA поддерживает ECDSA для подписи кода, поскольку это делает не каждый продукт.

Разверните Параметры ключа. Установите Размер ключа на 3072 или 4096. RSA 3072 — это минимум для подписи кода, и запрос, созданный с размером 2048, будет отклонён. Если раскрывающийся список не предлагает 3072 для выбранного провайдера, используйте 4096.

В той же группе оставьте флажок «Разрешить экспорт закрытого ключа» снятым. Это самая важная поправка к устаревшим инструкциям по MMC. Экспортируемый ключ можно скопировать с машины в виде файла .pfx, а именно это и должно предотвращать аппаратное требование, и путь с аттестацией явно подтверждает, что ключ был создан неэкспортируемым способом. Единственный случай, когда стоит установить этот флажок — внутренняя схема подписи, где сертификат и ключ необходимо перенести на другую машину, но даже тогда это ослабляет защиту ключа. Также оставьте флажок Разрешить архивирование закрытого ключа снятым. Усиленная защита закрытого ключа необязательна и заставляет Windows запрашивать подтверждение при каждом использовании ключа, что разумно для ключа подписи на общем рабочем компьютере.

Разверните Выбор алгоритма хеширования и установите Алгоритм хеширования на sha256. SHA-1 не допускается для сертификатов подписи кода.

Вкладку Расширения стоит проверить, если вы регистрируетесь через внутренний CA. Разверните Использование ключа и добавьте Цифровая подпись, затем разверните Расширенное использование ключа (политики приложений) и добавьте Подписывание кода. Публичный CA формирует сертификат исходя из заказанного вами продукта, а не из расширений в вашем запросе, поэтому для публичного заказа эта вкладка ничего не меняет. Внутренний CA может учесть её.

Нажмите ОК, чтобы закрыть окно Свойства сертификата, затем Далее.

Шаг 5: Сохраните запрос

Мастер спросит: Куда вы хотите сохранить автономный запрос? Нажмите Обзор, выберите контролируемую вами папку, дайте файлу имя, например codesigning.req, и подтвердите. Всегда переходите к папке через обзор, а не вводите просто имя файла: без указания пути запрос попадёт в ту папку, из которой в данный момент запущена консоль, что редко является тем местом, которое вам нужно, и потом его будет неудобно искать.

В разделе Формат файла оставьте выбранным Base 64. Это текстовая форма, которую CA вставляют в поле регистрации. Двоичный формат записывает необработанный DER, который большинство форм заказа отклоняют. Нажмите Готово.

Откройте файл в любом текстовом редакторе, например в Блокноте, и скопируйте весь блок, включая первую и последнюю строки:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEbDCCA1QCAQAwZDELMAkGA1UEBhMCVVMx...
...base64 encoded request...
-----END NEW CERTIFICATE REQUEST-----

Инструменты регистрации Windows обычно записывают более длинную формулировку, показанную выше, со словом NEW в маркерных строках, тогда как OpenSSL записывает BEGIN CERTIFICATE REQUEST и END CERTIFICATE REQUEST. Если ваш файл использует более короткую форму, ничего страшного: содержимое — это тот же запрос PKCS #10, и удостоверяющие центры принимают оба варианта. Копируйте в точности то, что видите, и не переписывайте маркерные строки.

Одна вещь, которую мастер не создаёт — это файл закрытого ключа, который можно сохранить или скопировать, и старые руководства, которые советуют сохранять файлы открытого и закрытого ключа, описывают другой инструмент. MMC хранит новый закрытый ключ внутри хранилища ключей Windows, под учётной записью, выбранной вами на шаге 1, только на этом компьютере. Ожидающий запрос обычно отображается в оснастке в разделе Заявки на регистрацию сертификатов. Из этого следуют три вещи:

• Не удаляйте ожидающий запрос, пока ждёте выпуска сертификата. Удаление отбрасывает ключ, и выпущенный сертификат станет бесполезным.
• Завершайте заказ на том же компьютере, в том же контексте учётной записи. Запрос, созданный в хранилище пользователя, нельзя завершить в хранилище компьютера, и наоборот.
• Не переустанавливайте систему и не создавайте новый образ машины в промежутке между созданием запроса и установкой сертификата.

Шаг 6: Проверьте запрос перед отправкой

После создания запрос нельзя отредактировать, поэтому проверьте его сейчас, а не обнаруживайте опечатку после начала проверки. Windows может считать его без каких-либо дополнительных программ. Откройте командную строку в папке с файлом и выполните:

certutil -dump codesigning.req

Если установлен OpenSSL, эта команда также считывает тот же файл и дополнительно проверяет подпись запроса:

openssl req -noout -text -verify -in codesigning.req

Убедитесь в четырёх вещах в выводе: субъект содержит страну, штат/область, населённый пункт, организацию и общее имя именно так, как вы задумали; открытый ключ имеет размер 3072 бита или больше, либо это утверждённая кривая ECDSA; алгоритм подписи — SHA-256; и, при использовании команды OpenSSL, что появляется строка verify OK, которая подтверждает, что запрос подписан соответствующим ему закрытым ключом. Вы также можете вставить блок в декодер CSR, чтобы прочитать его в браузере.

Если что-то не так, создайте новый запрос, начиная с шага 2. Чтобы увидеть, какие провайдеры доступны на машине, включая любые установленные вами аппаратные, выполните:

certutil -csplist

Шаг 7: Установите выпущенный сертификат на ту же машину

Отправьте блок в кодировке Base 64 при оформлении заказа сертификата, пройдите проверку, которую запрашивает CA, и загрузите выпущенный сертификат, когда он придёт. Поскольку закрытый ключ остался в хранилище ключей Windows, сертификат должен вернуться в то же хранилище, чтобы быть пригодным к использованию.

В той же оснастке щёлкните правой кнопкой мыши по Личное, выберите Все задачи, затем Импорт, и укажите мастеру на файл. Windows сопоставляет сертификат с ключом, который был сохранён из запроса, и ожидающая запись в разделе Заявки на регистрацию сертификатов исчезает. После этого откройте сертификат и проверьте, что вкладка Общие сообщает, что у вас есть закрытый ключ, соответствующий этому сертификату. Если эта строка отсутствует, сопоставление не произошло, и вы можете восстановить связь с помощью серийного номера сертификата:

certutil -repairstore My <serial-number>

Добавьте ключ -user, если сертификат принадлежит текущему пользователю, а не машине:

certutil -user -repairstore My <serial-number>

Отсюда ваш инструмент подписи выбирает сертификат из хранилища. Помните хранилище, которое вы выбрали на шаге 1: signtool читает хранилище My текущего пользователя, если вы не передали /sm для хранилища компьютера.

Другие способы создать тот же запрос описаны в руководствах CertReq, OpenSSL, Java Keystore и macOS Keychain Access. Вам также может пригодиться более широкий набор руководств по подписи кода или другие способы создать CSR.

Часто задаваемые вопросы