Сначала проверьте цепочку сертификата: если подпись относится к Developer ID G1, переиздайте затронутые установочные пакеты с корректным сертификатом G2 и проверьте их установку до срока истечения. Для уже выпущенного приложения с нотариальной отметкой и защищённой временной меткой правило не такое, как для PKG: прежнее приложение не следует автоматически считать сломанным или требующим переподписи. Apple указывает, что исходный Developer ID Certification Authority истекает 1 февраля 2027 года, а пакеты, подписанные затронутым сертификатом, после этой даты перестанут устанавливаться. Объявление Apple о сроке G1 и переходе на G2.
Кому пригодится: руководителям выпуска macOS-приложений, которым нужно установить, затронуты ли их активы подписи.
Инженерам CI/CD, обновляющим идентификатор подписи, связку ключей и проверки готовых пакетов.
Корпоративным IT-специалистам, планирующим изолированную среду Mac для тестирования миграции.
Последнее обновление: 26 октября 2026 года. Срок и правила сверены с объявлением Apple от 1 октября 2026 года и официальными инструкциями Apple по замене сертификатов.
Developer ID G1: проблема в цепочке, а не в одном названии
Слово «истекает» может означать разные вещи: окончание срока действия промежуточного центра сертификации либо отдельного Developer ID-сертификата. Это не одно и то же. Apple подтверждает, что G1 — исходный Developer ID Certification Authority, а сертификаты, выданные этим центром, перестанут работать с наступлением указанного срока. При этом сама дата окончания действия в списке сертификатов — лишь повод проверить актив, а не окончательное доказательство, что его выдал именно G1.
В корпоративной сборке важно проверять сертификат подписи приложения или установщика, который реально использует CI, и его издателя. Не ограничивайтесь названием вроде «Developer ID Installer»: сертификаты от разных промежуточных центров могут иметь одинаковое отображаемое имя. В инструкции Apple по идентификации и замене сертификатов предыдущего Sub-CA рекомендуется открыть именно сертификат разработчика в «Связке ключей», развернуть сведения об издателе и проверить поле Organizational Unit. Для сертификата прежнего центра там указано Apple Certification Authority, для действующего G2 — G2.
Проверяйте конечный сертификат, который содержит закрытый ключ и которым подписывается продукт, а не одноимённую запись промежуточного центра. В противном случае можно принять за доказательство неподходящий объект из цепочки и ошибочно объявить затронутыми все подписи команды.
Для инвентаризации полезно сопоставить три источника: запись сертификата в учётной записи разработчика, установленную идентичность на сборочном узле и подпись у выпущенного артефакта. Если между ними разные сертификаты, миграция учётной записи ещё не означает, что сборка переключилась на новую идентичность. Зафиксируйте Team ID, тип сертификата, дату окончания, издателя и имя узла, на котором создаётся продукт. Эти сведения помогут проследить, какая именно сборка использует G1, а какая уже перешла на G2.
Установщик PKG и приложение: последствия отличаются
Решение зависит не только от цепочки, но и от вида распространяемого продукта. По объявлению Apple, с 1 февраля 2027 года не будут устанавливаться .pkg, подписанные затронутым сертификатом. В то же время ранее подписанное и нотариально заверенное приложение с защищённой временной меткой продолжит работать; для его будущих обновлений следует использовать новый сертификат и включать защищённую временную метку при нотариальном заверении. Это не основание переносить правило для PKG на любой DMG, архив или приложение.
| Что проверяется | Официально указанное последствие | Решение для выпуска |
|---|---|---|
Установочный пакет .pkg, подписанный затронутым сертификатом |
С 1 февраля 2027 года он не будет устанавливаться | Переподписать новым сертификатом и проверить установку на целевой системе |
| Ранее выпущенное нотариально заверенное приложение с защищённой временной меткой | Продолжит работать; отдельная переподпись только из-за срока G1 не требуется | Сохранить артефакт и отдельно обновить процесс подписи для будущих выпусков |
| Будущее обновление приложения | Apple требует новый сертификат и защищённую временную метку для нотариального заверения | Проверить новую подпись, нотариальную обработку и сценарий обновления |
| Другой формат распространения | Объявление о сроке отдельно не устанавливает для всех форматов одинаковый результат | Проверять правила конкретного формата и фактический способ распространения |
Основание для различий в таблице — объявление Apple о G1. Слова «затронутый сертификат» здесь принципиальны: вывод не означает, что все старые PKG, приложения или все Developer ID-сертификаты автоматически утратят работоспособность.
Если при установке пакета появляется ошибка, сохраните текст ошибки, сам артефакт и вывод проверки подписи. Затем проверьте сертификат установщика и цепочку — не делайте вывод о причине по одному сообщению Gatekeeper.
Так можно отличить проблему подписи от проблем конкретной сборки, доставки или тестовой системы. На практике особенно легко перепутать два продукта одного выпуска: приложение внутри пакета может быть подписано Developer ID Application, а сам .pkg — отдельным сертификатом Developer ID Installer. Успешная проверка приложения не доказывает, что внешний контейнер подписан нужным сертификатом. Apple отдельно описывает назначения Developer ID Application и Developer ID Installer.
Сценарий из типичной корпоративной практики выглядит так: инженер запускает сборку приложения с новой идентичностью и получает корректно подписанный .app, но шаг упаковки по-прежнему выбирает старую идентичность Installer из связки ключей. Проверка приложения проходит, а опубликованный PKG остаётся подписан G1. Поэтому приёмка должна охватывать внешний установщик, а не только приложение до упаковки.
G2-сертификат: выбор промежуточного центра и роль Xcode
При создании замены проверьте тип сертификата и выберите Developer ID Certification Authority (G2), когда система предлагает промежуточный центр. Для приложения нужен Developer ID Application, для установочного пакета — Developer ID Installer; один сертификат не заменяет другой. Apple предупреждает, что выбор другого центра может привести к выпуску сертификата, который также окажется привязан к истекающему центру. В инструкции Apple по замене также приведено требование использовать совместимую версию Xcode при выборе G2.
До выпуска сертификата проверьте, какая версия Xcode установлена на машине администратора и на узлах, где управляются подпись и сборка. В объявлении Apple указано обновиться, если используется Xcode 11.4 или более ранняя версия; в руководстве по замене G2 указан вариант Xcode 11.4.1 или новее для выбора промежуточного центра. Это конкретное требование к созданию сертификата, а не гарантия, что обновление Xcode само по себе поменяет идентичность во всех сборочных сценариях.
После получения сертификата убедитесь, что на реальном CI-узле доступны и сертификат, и соответствующий закрытый ключ. Сам файл сертификата без закрытого ключа не образует рабочую подписывающую идентичность. Затем проверьте, что конфигурация сборки выбирает именно нужный тип сертификата и ожидаемую командой Team ID. При наличии нескольких одноимённых идентичностей не полагайтесь только на короткое имя: Apple рекомендует однозначно задавать идентичность по отпечатку, если имена совпадают. Подробности есть в документации Apple о подписании кода для распространения на Mac.
Ошибка в CI: сборка успешна, а миграция — нет
Зелёный статус задачи подтверждает, что скрипт завершился без обнаруженной им ошибки; он сам по себе не подтверждает, что сборка выбрала G2, что закрытый ключ доступен после перезапуска узла или что конечный PKG можно установить. Наиболее частые пробелы в проверке — доверие только настройке проекта, проверка .app вместо .pkg и отсутствие теста на узле, отличном от сборочного.
Перед включением новой подписи в рабочий выпуск заведите отдельный тестовый путь и зафиксируйте идентификатор используемой идентичности. Не публикуйте в логах закрытый ключ, пароль связки ключей, токены нотариального сервиса или другие секреты. В журнале достаточно хранить безопасные сведения для аудита: тип сертификата, команду проверки без секретных аргументов, результат, идентификатор артефакта и ссылку на защищённую запись о прохождении теста.
Для проверки подписи приложения можно использовать codesign --verify --strict --verbose=2 /путь/к/приложению. Для пакета Apple указывает проверку pkgutil --check-signature /путь/к/файлу.pkg: в выводе проверяются подпись, доверенная временная метка и цепочка. Синтаксис и интерпретацию результатов следует сверять с официальной документацией Apple по типичным проблемам нотариального заверения. Проверка метки у приложения и проверка подписи PKG — разные операции; одна не подменяет другую.
Проверка перехода в сборочной среде
Этап инвентаризации. Соберите перечень выпускаемых продуктов и разделите их на приложения, установочные пакеты и контейнеры других форматов. Для каждого элемента запишите, где создаётся подпись: в Xcode, командном скрипте или отдельном упаковочном задании. Это позволит не ограничиваться видимой настройкой проекта, если внешний PKG подписывается позже.
Этап идентификации. На каждом узле подписи найдите фактически используемые Developer ID Application и Developer ID Installer, затем сверьте издателя, связку ключей и доступность приватного ключа. Сопоставьте установленную идентичность с сертификатом в учётной записи. Если используется несколько одинаково названных сертификатов, привяжите настройку к уникальному идентификатору или отпечатку, а не к неоднозначной строке имени.
Этап создания замены. Создайте отдельные сертификаты нужных типов и при выборе центра укажите G2. Не отзывайте прежний сертификат до проверки того, что сборка и процесс выпуска используют новые данные: преждевременное удаление может затруднить сравнение результатов и воспроизведение старой сборки. Храните закрытый ключ в утверждённом командой хранилище секретов; не помещайте его в исходный код и не выводите содержимое в журнал.
Этап параллельного теста. На отдельной ветке или тестовом задании соберите представительный .app, подготовьте PKG тем же способом, что и для реального релиза, и проверьте оба артефакта. Для приложения используйте codesign; для установочного пакета — pkgutil. Затем выполните требуемую командой нотариальную обработку и проверьте, что тестовый пользовательский сценарий соответствует ожидаемому формату распространения. Инструкция Apple по нотариальному заверению macOS-программ описывает подпись и защищённую временную метку как часть подготовки продукта.
Этап установки. Установите созданный PKG на отдельной целевой системе или в контролируемом тестовом окружении. Проверка подписи отвечает на вопрос о сертификате и цепочке, но тест установки дополнительно показывает, что конкретный артефакт проходит пользовательский путь. Не подменяйте этот тест проверкой успешной сборки или запуском приложения из каталога сборки.
Этап сравнения и допуска. Сравните результат с исходной сборкой: идентичность приложения, идентичность установщика, цепочка, статус нотариальной обработки и итог установки. Сохраните версии скриптов, настройки идентификаторов без секретов, контрольные суммы артефактов и итог проверки. Установите критерий допуска до начала теста: если PKG не подтверждает новую цепочку или не устанавливается, публикация откладывается до выяснения причины, даже если сама задача сборки завершилась успешно.
Отдельная среда Mac и безопасная проверка выпуска
Для команд, где производственный CI нельзя менять без отдельной проверки, тестовый контур на реальном Mac помогает воспроизвести полный путь: импортировать нужную идентичность, собрать продукт, подписать приложение и PKG, выполнить предусмотренную нотариальную обработку и проверить установку. Такой контур должен соответствовать требованиям команды к доступу, хранению ключей, журналированию и удалению временных данных. Сам факт использования удалённого Mac не подтверждает изоляцию или соответствие корпоративным требованиям — эти свойства необходимо отдельно проверить по документации и условиям конкретного решения.
Перед выбором среды опишите минимально необходимые критерии: кто получает доступ к узлу, как доставляется закрытый ключ, где сохраняются результаты и как команда завершает тест без копирования секретов в общие логи. Для оценки подхода можно свериться с материалом о конфиденциальности данных, а варианты среды и связанные руководства посмотреть в разделе руководств. Если рассматривается временная удалённая среда на Mac, отдельный вариант размещения описан на странице Mac mini в Японии; пригодность и условия нужно сверить перед использованием, а не выводить из этого руководства.
Для миграции не требуется менять весь производственный конвейер одновременно. Сначала выберите один типовой продукт, пройдите проверки сертификата и установки, затем повторите их для остальных схем упаковки. Если команда распространяет несколько форматов, фиксируйте отдельный результат для каждого: официальное правило об установочных пакетах не следует автоматически применять ко всем форматам, а наличие нотариальной отметки у приложения не подтверждает подпись внешнего PKG.
Практическое решение для команды
До срока G1 сначала определите издателя сертификата, затем классифицируйте артефакты. Затронутые PKG нужно подписать правильной идентичностью G2 и проверить установкой; ранее выпущенное нотариально заверенное приложение с защищённой временной меткой не следует считать требующим немедленной переподписи только из-за этого события. Для обновлений приложения настройте новую подпись и временную метку, а для пакета отдельно проверьте Developer ID Installer и внешний установочный сценарий.
Если текущая среда не позволяет безопасно проверить G2 без риска затронуть релизный конвейер, разумно сначала выделить изолированный Mac для тестовой сборки и приёмки. Самостоятельная покупка оборудования подходит командам, которым нужен постоянный узел и полный физический контроль, но требует закупки и обслуживания; существующая CI-среда удобна, если уже обеспечивает необходимый контроль ключей; временная аренда Mac может подойти для ограниченного теста, но не заменяет проверку доступа, хранения секретов и пригодности среды. Если нужен отдельный контур лишь для проверки миграции, сначала изучите руководства и критерии приёмки на сайте xcodeops, а затем сверяйте условия удалённой среды с требованиями команды до передачи в неё подписывающих активов.
Проверьте перенос подписи на выделенном Mac mini
В xcodeops вы арендуете физический Mac mini для сборки и проверки установочных пакетов PKG в своей CI-системе.