На сборке отказала подпись или вы обнаружили сертификат от исходного Developer ID Sub-CA — выпуск не переводите сразу на новый ключ.
Быстрое решение: сначала проверьте Issuer и назначение сертификата; затронутый сертификат замените сертификатом от Developer ID Certification Authority (G2), затем примите подпись и нотариальное заверение в изолированном Mac CI. По объявлению Apple, исходный Sub-CA истекает 1 февраля 2027 года: затронутые установочные пакеты нужно переподписать до этой даты, а уже нотариально заверенные приложения с безопасной меткой времени не требуют переподписи только из-за этого истечения (объявление Apple).
Эта инструкция предназначена для инженеров, которые поддерживают подпись Developer ID, распространение приложений и нотариальное заверение. Если вы отвечаете за Mac CI и связки ключей, проверьте доступ к новой идентичности именно от имени пользователя задания. Если вы выпускаете приложения и установочные пакеты, принимайте их отдельно: у них разные сертификаты и критерии повторной подписи.
Последняя проверка: 7 ноября 2026 года. Сведения сверены с объявлением Apple об истечении исходного Sub-CA, инструкцией по замене сертификатов и описанием Developer ID.
Сначала определите, что именно затронуто
Не делайте вывод о необходимости переподписи только по дате, отображаемой в настройках сертификата. Сопоставьте издателя сертификата, его назначение и тип выпускаемого артефакта. Apple объявила, что исходный Developer ID Certification Authority (Sub-CA) истекает 1 февраля 2027 года; руководство предписывает создавать замену с использованием G2 Sub-CA. Это не равнозначно требованию переподписать каждое приложение, когда-либо подписанное Developer ID.
Разделите два типа идентичности:
- Developer ID Application используется для подписи приложения для распространения вне App Store. Проверяйте подпись приложения, её цепочку и применённую метку времени.
- Developer ID Installer предназначен для подписи установочного пакета
.pkg. Если пакет подписан сертификатом Installer от исходного Sub-CA, для него Apple задаёт отдельное действие — переподписать пакет до истечения исходного сертификата.
.pkg и не трактуйте истечение промежуточного сертификата как автоматическое требование заново подписать всё приложение. Критерии проверки должны соответствовать конкретному артефакту и фактической цепочке, а не названию задания или наличию слова Developer ID в журнале.
Важно: срок действия — удобный фильтр для поиска сертификатов, но не доказательство того, какой Sub-CA их выдал. Для решения о замене проверьте Issuer и проследите, какой файл сертификата использует рабочая задача.
Шаг 1. Проследите сертификат от учётной записи до задания CI
Составьте перечень всех мест, где выполняется подпись: сборочные узлы, отдельные задания упаковки, сценарии выпуска и резервные конвейеры. Для каждого запишите назначение сертификата, отображаемое имя идентичности, Issuer, срок действия, расположение связки ключей и пользователя, от имени которого запускается задание.
Начните с Certificates, Identifiers & Profiles и проверьте выпущенные сертификаты обоих типов — Application и Installer. Сверьте этот перечень с настройками Xcode, сценариями сборки и параметрами экспорта или упаковки. Наличие нового G2-сертификата в учётной записи не доказывает, что рабочая задача уже использует его; и наоборот, сертификат в связке ключей может не соответствовать актуальной записи в учётной записи разработчика.
На Mac CI команда security find-identity -v -p codesigning помогает увидеть доступные идентичности для подписи кода в текущей среде. Используйте её как проверку наличия, а не как единственный способ установить промежуточный центр. Для самой цепочки откройте сертификат в связке ключей и проверьте сведения об издателе; при экспортированной копии сертификата также можно изучить её поля сертификата средствами, доступными на вашем узле.
Для уже собранного приложения получите сведения о подписи командой codesign -dv --verbose=4 ПУТЬ_К_ПРИЛОЖЕНИЮ; для пакета проверьте издателя и статус подписи командой pkgutil --check-signature ПУТЬ_К_ПАКЕТУ.pkg. Эти команды помогают связать артефакт с подписью, но не заменяют изучение Issuer в самой цепочке. Описание проверки подписи и сертификатов приведено в руководстве Apple по проверке Code Signing.
Завершите инвентаризацию поиском скрытых ссылок на старую идентичность. Проверьте переменные CI, секреты, параметры экспорта, сценарии создания .pkg, имена профилей задания и инструкции для резервного узла. Зафиксируйте не только имя сертификата, но и отпечаток сертификата, назначение и связанный ключ. Так вы избежите ситуации, когда две идентичности с похожими именами присутствуют одновременно, а задание выбирает не ту.
Шаг 2. Выпустите подходящую замену и передайте её безопасно
В учётной записи разработчика создайте замену отдельно для каждой требуемой роли. Если ваш процесс подписывает приложение и упаковывает его в .pkg, обычно нужно проверить обе роли, а не считать, что один сертификат заменяет другой. Следуйте текущей инструкции Apple по замене сертификатов Developer ID: при создании укажите G2 Sub-CA и после выпуска убедитесь, что Issuer новой идентичности действительно соответствует G2.
Сверьте способ выпуска и ограничения используемой версии Xcode с действующей инструкцией Apple. Не основывайте решение на старом скриншоте, статье или памяти о том, какие варианты выбора были доступны в предыдущей версии инструментов. Если интерфейс учётной записи и ваш Xcode расходятся, сохраните сведения о версии инструментов, проверьте требования Apple и не переключайте производственный выпуск до успешной пробной сборки.
Отдельно согласуйте передачу сертификата и закрытого ключа. Сертификат без соответствующего закрытого ключа не позволит заданию подписывать; закрытый ключ, доступный не тому пользователю или не той связке ключей, может работать в интерактивной сессии и быть недоступен после перезапуска или в чистом задании CI. Назначьте владельца передачи, место хранения секретов, права доступа и процедуру отзыва старых учётных данных. Не включайте приватный ключ в репозиторий и не копируйте его без контроля в каждую среду.
Пока идёт миграция, не удаляйте старую идентичность из всех узлов без плана отката. Однако сохранение её на узле не должно превращаться в молчаливое продолжение использования: настройте явный выбор нового сертификата, а в журнале испытаний укажите фактический отпечаток. Когда замена прошла проверку, отдельно решите, где и когда удалить устаревшие секреты согласно правилам вашей команды.
Если у команды нет отдельной машины для пробного выпуска, можно сначала изучить руководство по удалённой среде Mac, а затем определить, подходит ли такая среда вашим требованиям к доступу и управлению ключами. Не переносите ключи на узел, пока не проверили собственные правила хранения и контроля доступа.
Шаг 3. Проведите изолированную проверку под реальным пользователем CI
Создайте отдельное задание, которое использует тот же образ сборки, параметры подписи, сценарии и системную учётную запись, что и выпуск, но не публикует релиз. Изоляция здесь означает контролируемую проверку без замены производственной линии: вы должны иметь возможность увидеть, какой сертификат выбран, проверить артефакт и остановить процесс до его распространения.
Проверьте задачу в порядке, который облегчает диагностику:
- Запустите задание с рабочим пользователем CI и убедитесь, что нужная идентичность видна в его контексте. Интерактивная проверка администратора не подтверждает доступ задания.
- Проверьте наличие закрытого ключа и разрешение на его использование. Если система запросила подтверждение доступа, убедитесь, что это не ручное действие, которое не сработает в безнадзорном запуске.
- Выполните сборку и подпишите тестовое приложение новой идентичностью Developer ID Application. Сохраните журнал и отпечаток использованного сертификата.
- Если конвейер выпускает
.pkg, отдельно сформируйте или подготовьте пакет с Developer ID Installer. Не подменяйте эту проверку успешной подписью приложения. - Отправьте требуемый артефакт на нотариальное заверение, затем дождитесь и проверьте итоговый результат. Успешная загрузка или принятый запрос — не то же самое, что положительный результат проверки Apple.
- Проверьте конечный артефакт, который будет передан пользователю: подпись, связанный билет нотариального заверения, если он используется, и возможность воспроизвести результат из задания.
notarytool и фиксируйте итоговый статус отдельно от результата подписи. [Документация Apple по рабочему процессу нотариального заверения из командной строки](https://developer.apple.com/documentation/security/customizing-the-notarization-workflow) описывает отправку, получение результата и работу с журналом; [руководство по нотариальному заверению macOS-программ перед распространением](https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution) помогает сопоставить эти действия с выпуском. Если вы используете прикрепление билета, дополнительно проверьте его командой xcrun stapler validate.
Критерий приёмки — не «команда подписи завершилась с кодом 0». В журнале должны быть три раздельных подтверждения: задание выбрало ожидаемую идентичность; нужный артефакт имеет действительную подпись; нотариальное заверение завершилось ожидаемым итогом. Для приложения и пакета сохраняйте отдельные записи, иначе при расследовании сбоя нельзя будет установить, на каком именно этапе остановилась поставка.
Шаг 4. Проверьте приложения и пакеты по разным критериям
Для приложения проверьте сведения codesign, затем выполните проверку подписи, подходящую вашей процедуре, например codesign --verify --deep --strict --verbose=2 ПУТЬ_К_ПРИЛОЖЕНИЮ. Сопоставьте Team Identifier и идентичность подписи с ожидаемыми значениями, проверьте, что нотариальное заверение действительно завершилось успешно, и подтвердите наличие безопасной метки времени там, где она требуется вашим процессом. Правила подписи и распространения Developer ID сверяйте с официальным описанием Developer ID от Apple.
Для .pkg используйте pkgutil --check-signature ПУТЬ_К_ПАКЕТУ.pkg и убедитесь, что подпись принадлежит ожидаемой идентичности Developer ID Installer. Затем сопоставьте пакет с исходным заданием выпуска: подпись приложения внутри пакета не доказывает, что сам установочный пакет подписан корректным сертификатом Installer. Установите, какие сохранённые релизные артефакты или зеркала содержат пакеты, подписанные затронутым сертификатом, и замените их до установленного Apple срока.
Практический разбор здесь сводится к четырём вопросам. Что за артефакт перед вами — приложение или установочный пакет? Какой сертификат фактически его подписал? Какой Issuer указан в цепочке? Какое подтверждение Apple уже получено — только отправка на нотариальное заверение или положительный результат? Если ответа на любой вопрос нет, выпуск не следует считать принятым.
Уже нотариально заверенное приложение с безопасной меткой времени не следует автоматически включать в массовую переподпись только из-за истечения исходного Sub-CA. Но это не отменяет проверку самого артефакта и не разрешает переносить такое заключение на пакет .pkg. При неоднозначной цепочке, неполных журналах или отсутствии результата нотариального заверения сначала восстановите доказательства для конкретного артефакта; не заменяйте их предположением по дате выпуска.
Сопоставьте варианты перед переводом выпуска
Таблица помогает выбрать действие для каждого результата проверки. Оценка риска здесь качественная: «высокий» означает, что артефакт нельзя выпускать без дополнительного действия, а «условный» — что сначала нужно подтвердить указанные свойства.
| Проверенный объект | Что подтверждено | Решение | Оценка готовности |
|---|---|---|---|
| Приложение подписано исходным Developer ID, нотариально заверено и имеет безопасную метку времени | Подтверждены подпись, результат заверения и метка времени | Не переподписывать только из-за истечения Sub-CA; сохранить доказательства проверки | Условная: подтверждения должны относиться к этому артефакту |
| Приложение использует затронутую цепочку, но результат заверения или метка времени не подтверждены | Есть пробел в доказательствах | Остановить автоматическое заключение; проверить цепочку и завершить процедуру нотариального заверения по правилам выпуска | Низкая до получения подтверждений |
.pkg подписан Developer ID Installer от исходного Sub-CA | Подтверждены тип пакета и Issuer | Создать замену Installer через G2, переподписать пакет и проверить новый файл до 1 февраля 2027 года | Высокий риск до замены |
| Задание уже использует сертификат G2, но проверка сделана только вручную | Не доказано, что ключ доступен рабочему пользователю CI | Повторить пробный запуск под пользователем задания и сохранить журналы подписи и нотариального заверения | Средняя до автоматизированного прогона |
| Issuer или назначение сертификата неизвестны | Воздействие не классифицировано | Не выпускать заключение по дате; найти цепочку сертификата и определить Application это или Installer | Низкая до идентификации |
Шаг 5. Распространите замену по узлам и сохраните откат
После успешного изолированного испытания обновляйте рабочие узлы поэтапно. Начните с одного узла или одного непубликующего задания, внесите новую идентичность в управляемое хранилище секретов и проверьте выпуск с теми же параметрами, которые использовались в тесте. Затем применяйте замену к следующей группе задач. Так вы обнаружите узел, который ссылается на локальную связку ключей, неподдерживаемый сценарий или секрет с прежним сертификатом, до того, как он станет единственной точкой выпуска.
Для каждого этапа сохраняйте контрольные данные: отпечаток сертификата, роль Application или Installer, Issuer, имя задания, пользователя запуска, версии инструментов, журналы подписи и итог нотариального заверения. Запишите, какой артефакт был проверен, и где хранится его контрольная копия. Такой журнал позволяет при сбое отличить проблему сертификата от проблемы доступа к ключу, конфигурации задания или содержимого пакета.
Подготовьте откат как управляемое действие, а не как возврат к неопределённой старой настройке. Укажите, кто имеет право его выполнить, какое задание можно восстановить и как избежать публикации артефакта с уже выявленной проблемой. После переключения повторно проверьте резервный путь выпуска: наличие сертификата в связке ключей ещё не подтверждает, что резервный узел способен подписать и нотариально заверить файл без ручного вмешательства.
Шаг 6. Перепроверьте статус и календарь сертификатов
После переноса проверьте Certificates, Identifiers & Profiles и сведения на каждом узле, где осталась производственная подпись. Сопоставьте Issuer, назначение, срок действия и отпечаток с записью о выпуске. Отдельно убедитесь, что удалены ссылки на старый сертификат из CI-секретов и сценариев, которые больше не должны его выбирать. Сами правила хранения и удаления закрытых ключей должны соответствовать политике вашей команды.
Добавьте повторную проверку сертификатов в календарь обслуживания релиза: ориентируйтесь на актуальные инструкции Apple, а не на дату, скопированную в старый runbook. Ваша контрольная запись должна включать владельца сертификата, назначение, Issuer, срок действия и место, где выполняется подпись. Если Apple обновит руководство, дату истечения или порядок замены, пересмотрите процедуру до следующего выпуска, а не после ошибки в производственном задании.
Если у команды пока нет отдельного Mac для изолированной проверки, сравните аренду удалённой среды с локальным узлом и другими вариантами в руководстве по стоимости аренды Mac. Отдельный узел может быть полезен для временного прогона, но вам всё равно нужно самостоятельно оценить доступ к ключам, требования безопасности и пригодность среды для конкретного процесса.
Часто задаваемые вопросы
Как определить Sub-CA, если в CI отображается только имя сертификата?
Имя идентичности в выводе CI — не достаточное подтверждение. Найдите сертификат, который реально использует задание, и откройте его сведения о цепочке, чтобы проверить поле Issuer. Сопоставьте его с исходным Developer ID Certification Authority или G2; затем проверьте назначение и отпечаток. Дата истечения помогает сузить поиск, но решение о замене принимайте по издателю и роли сертификата.
Какие этапы принять после выдачи сертификата G2?
Запустите пробное задание под тем же пользователем, что выполняет релиз, и докажите, что этому процессу доступны сертификат и закрытый ключ. Проверьте выбранный отпечаток, подпишите тестовый артефакт, отправьте его на нотариальное заверение и зафиксируйте конечный статус. Если выпускается .pkg, отдельно подтвердите подпись Installer. Ручная подпись в сеансе администратора не заменяет эту проверку.
Нужно ли переподписать .pkg, если приложение внутри уже нотариально заверено?
Проверяйте сам .pkg: подпись встроенного приложения и подпись установочного пакета — разные уровни. Если пакет подписан затронутым Developer ID Installer от исходного Sub-CA, замените сертификат Installer на G2 и подпишите пакет заново до 1 февраля 2027 года. После этого проверьте подпись нового файла и сохраните его как замену во всех местах распространения.
Требует ли истечение исходного Sub-CA переподписи уже нотариально заверенного приложения?
Само по себе — нет, если приложение уже нотариально заверено и содержит безопасную метку времени: Apple отдельно указывает, что такие приложения не требуется переподписывать только из-за этого события. Убедитесь, что это действительно приложение, а не установочный пакет, и сохраните доказательства нотариального заверения и метки времени для конкретного артефакта. Не распространяйте это исключение на .pkg.
Если ваш выпуск сейчас зависит от одного Mac или ручной подписи, временная изолированная среда поможет проверить реальный сценарий до переключения производственной линии. Но для постоянных тяжёлых задач или процесса с обязательным физическим оборудованием отдельный собственный Mac может быть обоснованнее; для ограниченной проверки, миграции сертификата или временного тестового задания аренда Mac у MACGPU может избавить от покупки узла, который большую часть времени простаивает. Выбирайте её только после проверки требований к доступу и обращению с ключами, а затем сохраните те же доказательства приёмки, что и для собственного CI.