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

Сертификат подписи кода подтверждает, кто опубликовал программное обеспечение, и показывает, что код не изменялся с момента подписания. Чтобы заказать такой сертификат, необходимо создать CSR (запрос на подпись сертификата) — блок закодированного текста, который удостоверяющий центр (CA) использует для вашей идентификации и выдачи сертификата. CSR для подписи кода подчиняются иным правилам, чем CSR, создаваемые для веб-сайта, и эти правила изменились в 2023 году. В этом руководстве описан актуальный процесс и методы, которые всё ещё применимы.

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

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

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

• Предварительно настроенный аппаратный токен от CA. Удостоверяющий центр создаёт пару ключей и CSR непосредственно на сертифицированном USB-токене, устанавливает на него выданный сертификат и отправляет токен вам. Подписание выполняется с подключённым токеном. При этом способе вы не создаёте CSR самостоятельно.
• Собственный HSM или облачный HSM с аттестацией ключа. Если у вас уже есть совместимый аппаратный модуль безопасности (Hardware Security Module) или облачный HSM, например AWS CloudHSM, Azure Dedicated HSM или Google Cloud HSM, вы создаёте ключ и CSR на этом устройстве и предоставляете файл аттестации, который подтверждает CA, что ключ был создан на совместимом аппаратном устройстве и не может быть экспортирован с него.

Выбор пути определяется при оформлении заказа. Сравнение вариантов см. в статье о способах доставки сертификата подписи кода.

Вариант 1: токен с доставкой (CSR создаёт удостоверяющий центр)

Этот путь выбирают большинство частных лиц и небольших команд, поскольку он не требует собственного аппаратного обеспечения. При выборе варианта «токен с доставкой» при оформлении заказа удостоверяющий центр самостоятельно создаёт ключ и CSR на сертифицированном токене со своей стороны, а затем отправляет вам токен с уже загруженным сертификатом. Вам не нужно вставлять CSR в форму заказа.

Что нужно сделать вместо этого:

• Пройти этапы проверки, которые требует CA (проверка организации или личности).
• Дождаться получения физического токена.
• Установить драйверы токена (обычно SafeNet Authentication Client) и подписывать программное обеспечение при подключённом токене.

Вариант 2: создание CSR на собственном HSM или токене

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

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

Для облачных HSM (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM) создайте ключ внутри HSM, экспортируйте CSR и файл аттестации, который формирует платформа, и отправьте оба файла своему удостоверяющему центру при оформлении заказа.

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

• Используйте ключ RSA размером не менее 3072 бит или эквивалентный ключ ECDSA, как указано в базовых требованиях.
• Отметьте ключ как неэкспортируемый, чтобы он не мог покинуть устройство.
• Создавайте аттестацию одновременно с ключом. CSR без действительной аттестации будет отклонён.

Место методов OpenSSL, Java Keytool, MMC, CertReq и Keychain в новых условиях

Возможно, вы встречали более старые инструкции по созданию CSR для подписи кода с помощью OpenSSL, утилиты Java keytool, консоли управления Microsoft (MMC), команды Windows certreq или Keychain Access в macOS. Сами по себе эти инструменты создают ключ программным способом, поэтому CSR, созданный таким образом, сегодня недействителен для публично доверенного сертификата подписи кода.

Они всё же остаются полезными, если направлены на совместимое аппаратное обеспечение, а не на программное хранилище ключей. Например, OpenSSL может создать CSR для HSM через модуль PKCS#11, а CertReq или MMC может сформировать запрос с использованием аппаратного поставщика хранения ключей. Используйте эти материалы только в таком контексте и всегда сопровождайте запрос аттестацией устройства:

• Создание CSR для подписи кода с помощью OpenSSL
• Создание CSR для подписи кода с помощью Java Keystore
• Создание CSR для подписи кода с помощью CertReq
• Создание CSR для подписи кода с помощью консоли управления Microsoft
• Создание CSR для подписи кода с помощью macOS Keychain Access

Проверьте содержимое вашего CSR

Перед отправкой CSR убедитесь, что данные субъекта указаны верно. Если у вас установлен OpenSSL, декодируйте запрос локально и просмотрите его в текстовом виде:

openssl req -noout -text -in codesigning.csr

Проверьте название организации или общее имя, а также размер ключа в выводе команды. Стандартный инструмент проверки CSR для веб-сайтов здесь не подходит, поскольку CSR для подписи кода привязан к аппаратному устройству и проверяется через аттестацию, а не через публичное сканирование HTTPS.

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