bg-tutorials

Как сгенерировать CSR для сертификата подписи кода на macOS с помощью Keychain Access

Связка ключей (Keychain Access) по-прежнему присутствует на каждом Mac, и её Certificate Assistant всё так же создаёт запросы на подпись сертификата. Но будет ли этот запрос пригоден для подписи кода, полностью зависит от того, какой сертификат вы заказываете. Для сертификата Apple Developer ID, который позволяет распространять ПО для Mac вне Mac App Store, Keychain Access остаётся правильным инструментом, и приведённые ниже шаги актуальны. А для коммерческого сертификата для подписи кода от публичного удостоверяющего центра — того типа, который используется для подписи исполняемых файлов Windows, установщиков, драйверов и приложений Java, — запрос, созданный в Keychain Access, не принимается с 1 июня 2023 года, поскольку закрытый ключ теперь обязательно должен создаваться на аппаратном устройстве.

Сначала определите, какой из этих двух сертификатов вам нужен, а затем переходите к соответствующему разделу.

Какой именно сертификат для подписи кода вам нужен?

Оба продукта называются сертификатами для подписи кода, и оба подтверждают, кто опубликовал программное обеспечение, но они выпускаются разными центрами и подчиняются разным правилам. Читатели попадают на эту страницу потому, что Apple и публичные удостоверяющие центры используют одни и те же термины для двух разных вещей.

  • Сертификат Apple Developer ID. Выдаётся компанией Apple через её собственный удостоверяющий центр Developer ID Certification Authority участникам программы Apple Developer Program. Он используется для подписи приложений Mac, плагинов и установочных пакетов, которые вы распространяете самостоятельно, чтобы macOS Gatekeeper распознавал вас как идентифицированного разработчика. Пара ключей создаётся на вашем Mac и хранится в вашей связке ключей входа, а запрос вы формируете в Keychain Access.
  • Публично доверенный сертификат для подписи кода. Приобретается у публичного удостоверяющего центра, такого как Sectigo, DigiCert или GlobalSign. Он используется для подписи исполняемых файлов Windows, установщиков MSI, драйверов, скриптов PowerShell и приложений Java. Его выпуск регулируется базовыми требованиями CA/Browser Forum для подписи кода (Code Signing Baseline Requirements), которые требуют, чтобы закрытый ключ создавался и хранился на сертифицированном аппаратном устройстве, поэтому Keychain Access здесь не задействован.

Краткое правило принятия решения: если программное обеспечение, которое вы подписываете, работает на macOS и вы распространяете его вне Mac App Store, вам нужен сертификат Developer ID. Если вы подписываете что-либо для Windows или приложение Java, вам нужен коммерческий сертификат для подписи кода, даже если вы собираете его на Mac. Ни один из них не является сертификатом SSL/TLS. Если вам на самом деле нужен HTTPS для сервера на Mac, воспользуйтесь руководством как сгенерировать CSR на серверах macOS.

Коммерческий путь: почему метод через Keychain больше не применяется

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

Ключ, созданный в Certificate Assistant, по своей природе не проходит эту проверку по трём отдельным причинам:

  • Ключ представляет собой экспортируемый программный ключевой материал. Он записывается в вашу связку ключей входа, и вы можете выбрать его и экспортировать в виде файла .p12. Эта переносимость удобна для разработки под Apple, но именно её и призвано устранить аппаратное требование.
  • Размер ключа не соответствует требованиям. Базовые требования устанавливают минимум RSA 3072 бита для подписи кода, а меню Key Size (Размер ключа) в Certificate Assistant не предлагает варианта 3072.
  • Запрос содержит почти никакой идентификационной информации. Certificate Assistant запрашивает только общее имя (Common Name) и адреса электронной почты. Там негде указать данные об организации, населённом пункте, регионе или стране, которые удостоверяющий центр проверяет для сертификата подписи кода с проверкой организации.

Остаётся два допустимых способа получить публично доверенный сертификат для подписи кода, и выбор одного из них делается при оформлении заказа:

  • Токен с доставкой. Удостоверяющий центр самостоятельно генерирует пару ключей и запрос на сертифицированном USB-токене на своей стороне, записывает на него выпущенный сертификат и отправляет токен вам по почте. Вам не нужно создавать или где-либо вставлять CSR. См. раздел какой метод доставки сертификата подписи кода выбрать.
  • Собственный аппаратный токен, HSM или облачный HSM с аттестацией. Вы создаёте ключ внутри устройства, формируете там же запрос и подаёте файл аттестации, подтверждающий, что ключ был создан на соответствующем требованиям аппаратном обеспечении и не может быть экспортирован. Следуйте руководству генерация CSR и аттестация для YubiKey 5 FIPS или руководству CSR и аттестация для Luna Network Attached HSM v7.x, либо документации вашего поставщика HSM.

Ещё одно уже вступившее в силу изменение: постановление CSC-31 сократило максимальный срок действия публично доверенных сертификатов для подписи кода с 39 месяцев до 460 дней для сертификатов, выпущенных начиная с 1 марта 2026 года, поэтому теперь продление требуется примерно каждые 15 месяцев. Более широкую картину вы найдёте в руководствах как сгенерировать CSR для сертификата подписи кода и версия того же руководства для OpenSSL.

Создание CSR в Keychain Access для сертификата Apple Developer ID

Если вы уже сохранили файл .certSigningRequest, перейдите сразу к разделу отправка запроса в аккаунте разработчика.

Перед началом нужно проверить два момента. Вам необходимо членство в программе Apple Developer Program, и Apple требует роль Account Holder (владелец аккаунта) для создания сертификата Developer ID. Также вам разрешено иметь до пяти сертификатов Developer ID Application и пяти сертификатов Developer ID Installer на команду. Портал запрашивает загрузку запроса при каждом создании сертификата, поэтому проходите этот процесс один раз для каждого сертификата.

Шаг 1: Откройте Keychain Access и начните запрос

Keychain Access больше не находится там, где указывает большинство руководств. Вплоть до macOS Sonoma это приложение располагалось в Applications > Utilities. Начиная с macOS Sequoia, Apple перенесла его в системную папку /System/Library/CoreServices/Applications/, которую Finder не показывает при просмотре папки Applications, поэтому поиск в Utilities теперь ничего не даёт. Быстрее всего открыть его через Spotlight (нажмите Command-Space и введите Keychain Access) или с помощью одной команды в Терминале:

open "/System/Library/CoreServices/Applications/Keychain Access.app"

После открытия приложения выберите в строке меню Keychain Access > Certificate Assistant > Request a Certificate From a Certificate Authority.

Перед этим щёлкните по пустой области списка элементов, чтобы ничего не было выделено. Если выделен ключ или сертификат, пункт меню изменится на Request a Certificate From a Certificate Authority With, за которым следует название этого элемента, и запрос будет сформирован на основе существующего ключа, а не создания новой пары. Это полезно, если вы намеренно хотите повторно использовать ключ, и может сбить с толку, если это не так.

Открытое меню Keychain Access с выделенным пунктом Certificate Assistant и Request a Certificate From a Certificate Authority

Шаг 2: Заполните окно Certificate Information

Certificate Assistant открывается на панели с заголовком Certificate Information. Она запрашивает очень немного данных:

  • User Email Address: адрес электронной почты, привязанный к вашему аккаунту Apple Developer.
  • Common Name: метка для пары ключей, например Developer ID Application Key. Это не то имя, которое в итоге окажется в сертификате. Apple формирует субъект выпущенного сертификата на основе вашей команды в формате Developer ID Application: Your Team Name (TEAMID), так что относитесь к этому полю как к собственной пометке для себя.
  • CA Email Address: оставьте пустым. Оно используется только для другого способа доставки.
  • Request is: выберите Saved to disk, а не Emailed to the CA. Портал разработчика Apple принимает загруженный файл.

Если вы также хотите выбрать размер ключа или алгоритм, отметьте здесь пункт Let me specify key pair information. Затем нажмите Continue.

Панель Certificate Information в Certificate Assistant с полями User Email Address, Common Name и CA Email Address и выбранным вариантом Saved to disk

Шаг 3: При необходимости выберите параметры пары ключей

Эта панель появляется, только если вы отметили флажок в шаге 2, и для сертификата Developer ID её обычно можно пропустить. Значения по умолчанию — RSA размером 2048 бит, именно это использует собственная инструкция Apple. При выбранном RSA меню Key Size предлагает 2048, 4096 и 8192 бита. Меню Algorithm предлагает RSA и ECC, и при переключении на ECC эти размеры заменяются на 256, 384 и 521 бит. Оставьте алгоритм RSA, если только сервис, в котором вы регистрируетесь, не требует явно ключ на основе эллиптической кривой.

В более ранних версиях этого руководства рекомендовалось выбирать здесь минимум 3072 бита. Это значение является минимумом CA/Browser Forum для коммерческих сертификатов подписи кода. Оно не применяется к Developer ID и не предлагается в этом меню, так что выбирать здесь нечего. Нажмите Continue.

Панель Specify Key Pair Information в Certificate Assistant с меню Key Size и Algorithm

Шаг 4: Сохраните запрос и проверьте его содержимое

Выберите, куда сохранить файл, и нажмите Save. Вы получите файл с расширением .certSigningRequest, а Certificate Assistant также поместит соответствующую пару ключей в вашу связку ключей входа. Сам файл представляет собой обычный текст в формате PEM, поэтому вы можете открыть его в TextEdit и прочитать, хотя закодированный блок сам по себе мало что скажет.

Файл запроса на подпись сертификата, открытый в TextEdit, с маркерами BEGIN и END CERTIFICATE REQUEST вокруг закодированного блока

Чтобы проверить данные перед загрузкой, декодируйте запрос в Терминале. Это работает с командой openssl, уже установленной в macOS, которая на самом деле является LibreSSL, а не настоящим OpenSSL, так что устанавливать ничего не нужно:

openssl req -noout -text -in CertificateSigningRequest.certSigningRequest

В выводе проверьте три вещи: строка Subject должна показывать введённые вами общее имя и адрес электронной почты, строка публичного ключа должна указывать 2048 bit (или выбранный вами размер), а алгоритм подписи должен быть SHA-256. Если вы предпочитаете не использовать Терминал, вставьте содержимое файла в наш декодер CSR, чтобы прочитать те же поля.

Шаг 5: Отправьте запрос и установите сертификат

Войдите в свой аккаунт Apple Developer и откройте раздел Certificates, Identifiers & Profiles. Нажмите Certificates на боковой панели, затем кнопку добавления, и в разделе Software выберите Developer ID. Выберите нужный тип:

  • Developer ID Application для подписи приложения Mac, плагина или пакета.
  • Developer ID Installer для подписи установочного пакета Mac, содержащего ваше подписанное приложение.

Нажмите Continue, затем Choose File, выберите файл .certSigningRequest, снова нажмите Continue и нажмите Download. Apple вернёт файл сертификата с расширением .cer. Дважды щёлкните по нему, чтобы установить, и он появится в Keychain Access в разделе My Certificates, в паре с закрытым ключом, созданным на шаге 4.

Подпись сертификатом — это лишь половина того, что проверяет macOS. Gatekeeper ожидает, что программное обеспечение, загруженное вне Mac App Store, будет подписано сертификатом Developer ID и нотаризовано Apple, поэтому отправьте подписанную сборку на нотаризацию перед распространением. Нотаризация не заменяет подпись, она дополняет её.

Найдите закрытый ключ и создайте его резервную копию

Сертификат бесполезен без закрытого ключа, созданного Certificate Assistant, а этот ключ существует ровно в одном месте, пока вы его не скопируете. Чтобы найти его, откройте Keychain Access, выберите связку ключей login, затем категорию Keys, и найдите общее имя, которое вы ввели на шаге 2. Вы увидите две записи под этим именем: публичный ключ и закрытый ключ. Обратите внимание, что публичный ключ — это не ваш CSR: CSR — это файл .certSigningRequest, который вы сохранили на диск.

Keychain Access, показывающий пару публичного и закрытого ключей, созданную Certificate Assistant в связке ключей входа

После установки файла .cer посмотрите в разделе My Certificates. Там сертификат и его закрытый ключ отображаются как единая запись — это идентификатор подписи, который используют codesign, Xcode и ваши сборочные скрипты. Чтобы перенести этот идентификатор на другой Mac или на сервер сборки, щёлкните правой кнопкой мыши по записи и выберите Export, что создаст файл .p12, защищённый паролем, который вы установите. Храните этот файл так же, как хранили бы любой ключ подписи, потому что любой, у кого есть этот файл и пароль, может подписывать программное обеспечение от вашего имени.

Создайте резервную копию заранее. Сертификаты Developer ID действительны в течение пяти лет и не могут быть продлены: по истечении срока действия создаётся замена. Если вы потеряете закрытый ключ, сертификат больше нельзя будет использовать, и придётся создать новый, что израсходует один из ваших пяти слотов Developer ID Application или пяти слотов Developer ID Installer. Не поддавайтесь искушению отозвать устаревший сертификат для наведения порядка. Apple прямо указывает, что приложение, подписанное отозванным сертификатом Developer ID, не установится и не запустится у пользователя, у которого оно уже есть, поэтому отзыв нарушит работу всех уже распространённых копий. Отзывайте сертификат только в случае реальной кражи ключа, и будьте готовы к таким последствиям.

Одно замечание для тех, кто попал сюда в поисках коммерческого сертификата: если вы уже создали пару ключей в Keychain Access для заказа у публичного удостоверяющего центра, её нельзя использовать, и ни один УЦ её не примет. Ничего страшного не случится, если оставить её на месте, но нет особого смысла хранить экспортируемый ключевой материал для подписи в связке ключей. Выберите и публичный, и закрытый ключ в разделе Keys и удалите их, а затем оформите заказ через токен или HSM.

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

Можно ли по-прежнему создать CSR для подписи кода с помощью Keychain Access?

Для сертификата Apple Developer ID — да, и это метод, задокументированный самой Apple. Для публично доверенного сертификата подписи кода от коммерческого удостоверяющего центра — нет. С 1 июня 2023 года такие закрытые ключи должны создаваться и храниться на аппаратном криптографическом модуле, соответствующем стандарту FIPS 140-2 Level 2, Common Criteria EAL4+ или эквивалентному, а ключ, созданный в Keychain Access, представляет собой экспортируемый программный ключевой материал.

Где находится Keychain Access в текущей версии macOS?

В папке /System/Library/CoreServices/Applications/. Apple перенесла его туда в macOS Sequoia, поэтому его больше нет в Applications > Utilities, и оно не отображается при просмотре папки Applications в Finder. Откройте его через Spotlight или выполните команду open "/System/Library/CoreServices/Applications/Keychain Access.app" в Терминале. Отдельное приложение Passwords, представленное вместе с этим изменением, работает только с паролями, а не с сертификатами и ключами.

Какой размер ключа выбрать в Certificate Assistant?

RSA 2048 бит для сертификата Developer ID — это значение по умолчанию, поэтому можно оставить флажок Let me specify key pair information неотмеченным. При выборе RSA меню Key Size предлагает 2048, 4096 и 8192 бита, а при переключении на ECC эти значения заменяются на 256, 384 и 521 бит. Ни в одной настройке не предлагается 3072 бита — это минимум CA/Browser Forum для коммерческих сертификатов подписи кода, и это одна из нескольких причин, почему данный путь не подходит для коммерческого заказа.

Почему Certificate Assistant не запрашивает название компании, город или страну?

Потому что формируемый им запрос содержит только общее имя и адреса электронной почты. Apple не нужно больше данных: она заполняет субъект сертификата Developer ID на основе вашего аккаунта разработчика. Коммерческому удостоверяющему центру, напротив, нужны данные об организации, которые он проверяет по публичным записям, — это ещё одна причина, почему запрос из Keychain не подходит для такого заказа.

Нужен ли аппаратный токен для сертификата Apple Developer ID?

Нет. Правило CA/Browser Forum об аппаратном обеспечении применяется к публично доверенным сертификатам подписи кода, выпускаемым коммерческими удостоверяющими центрами. Сертификаты Developer ID выпускаются собственным удостоверяющим центром Apple для участников программы Apple Developer Program, а ключ создаётся в вашей связке ключей входа с помощью Certificate Assistant, как описано выше.

Нужен ли отдельный CSR для Developer ID Application и Developer ID Installer?

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

Я сохранил CSR, но не могу найти закрытый ключ. Что пошло не так?

Проверьте категорию Keys связки ключей login, выполняя поиск по введённому вами общему имени, а не по имени файла. Если ключа действительно нет, обычными причинами являются создание пары ключей на другом Mac или под другой учётной записью пользователя, удаление элемента связки ключей, либо формирование запроса на основе существующего ключа через вариант меню Request a Certificate From a Certificate Authority With. Без закрытого ключа запрос использовать нельзя, поэтому создайте новый.

Каков срок действия сертификата подписи кода?

Публично доверенные сертификаты подписи кода, выпущенные начиная с 1 марта 2026 года, ограничены сроком в 460 дней вместо прежних 39 месяцев согласно постановлению CA/Browser Forum CSC-31. Сертификаты Apple Developer ID действительны в течение пяти лет и заменяются, а не продлеваются. В обоих случаях программное обеспечение, подписанное в период действия сертификата, продолжает работать и после истечения срока его действия, при условии, что подпись была снабжена меткой времени. Apple применяет одно исключение: сертификат Developer ID Installer проверяется в момент запуска установочного пакета, поэтому файл .pkg необходимо переподписать после истечения срока действия этого сертификата, хотя само приложение внутри него не затрагивается.

Дополнительно рекомендуем ознакомиться с нашими руководствами по подписи кода, другими способами сгенерировать CSR, а также руководством как подписать файл EXE с помощью сертификата подписи кода.

Сэкономьте 10% на SSL-сертификатах при заказе сегодня!

Быстрая выдача, надежное шифрование, 99,99% доверия к браузеру, специализированная поддержка и 25-дневная гарантия возврата денег. Код купона: SAVE10

Детальное изображение дракона в полете
Написано

Опытный автор контента, специализирующийся на SSL-сертификатах. Превращает сложные темы кибербезопасности в понятный, увлекательный контент. Вносите свой вклад в повышение уровня цифровой безопасности с помощью впечатляющих рассказов.