Миграция сертификата Developer ID G2: приёмка подписи Mac в 2026 году

По объявлению Apple, опубликованному 1 октября 2026 года, прежний Developer ID Certification Authority истекает 1 февраля 2027 года (объявление Apple о сроке действия). Поэтому сначала проверьте издателя сертификата, а затем разделите поставляемые файлы: затронутый пакет .pkg нужно подписать сертификатом-заменой до указанного срока, но уже нотарифицированное приложение с безопасной меткой времени не следует автоматически считать требующим повторной подписи.

Кому пригодится: независимому разработчику, распространяющему приложение вне Mac App Store и проверяющему свою цепочку подписания.
Команде выпуска Mac-программ, которой нужно обновить подпись установочного пакета и принять новую сборку.
Инженеру CI/CD, отвечающему за сертификаты, закрытый ключ, связку ключей и задачи публикации.

Последняя проверка: 28 октября 2026 года. Срок, влияние на поставляемые файлы и порядок замены сверены с официальным объявлением Apple, инструкцией по замене сертификатов и справкой о промежуточном сертификате Developer ID.

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

В списке сертификатов легко заметить знакомую формулировку Developer ID, но её недостаточно для решения о миграции. Отображаемое имя и дата окончания действия — не надёжная замена проверке того, какой центр сертификации выдал конкретный сертификат. Apple отдельно объясняет замену сертификатов и область влияния; для определения цепочки используйте официальные сведения, а не догадки по имени (инструкция Apple по замене Developer ID).

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

1. Войдите в учётную запись разработчика Apple и откройте список сертификатов. Найдите записи типов Developer ID Application и Developer ID Installer, включая действующие сертификаты и те, которые используются в автоматической публикации.
2. На Mac откройте связку ключей и найдите соответствующие сертификаты. Просмотрите сведения о сертификате и его издателе; если интерфейс позволяет, проверьте также цепочку сертификатов.
3. Сопоставьте найденные записи с учётной записью: убедитесь, что сертификат относится к нужной команде, а рядом доступен соответствующий закрытый ключ. Сам сертификат без закрытого ключа не даёт CI возможности подписывать от его имени.
4. Разделите найденные сертификаты по назначению. Developer ID Application предназначен для подписи приложения; Developer ID Installer используется при подписании установочного пакета. Это разные идентичности, и наличие нового сертификата одного типа не означает, что второй тоже заменён.
5. Если издатель неясен или данные в связке ключей расходятся с учётной записью, не выпускайте артефакт на основании предположения. Сверьте процедуру с официальной инструкцией Apple и проверьте, какой сертификат фактически выбрала задача сборки.

Apple описывает типы сертификатов Developer ID отдельно (справка Apple о сертификатах Developer ID). Для команды это важно не только как формальность: замена сертификата приложения не исправит подпись .pkg, если установщик выпускается с другой, не обновлённой идентичностью.

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

Команде выпуска: оцените риск отдельно для приложения и установщика

Практическое решение зависит не от того, что продукт называется «Mac-приложением», а от того, какой именно артефакт пользователь скачивает и запускает. Apple проводит различие между приложениями с безопасной меткой времени, прошедшими нотариальную проверку, и затронутыми установочными пакетами. В официальном объявлении указано, что ранее подписанное и нотарифицированное приложение с безопасной меткой времени продолжит работать; затронутые .pkg необходимо подписать заново до 1 февраля 2027 года (объявление Apple с областью влияния).

Оценка риска в таблице — инструмент планирования, а не отдельная гарантия поведения macOS. Для конкретного продукта решающими остаются тип артефакта, издатель сертификата и результат проверки подписи. В справке Apple о сертификатах Developer ID описаны их назначения и контекст использования.

Приёмку организуйте по фактическим поставляемым файлам. Сначала обновите сертификат нужного типа, затем создайте подписанный артефакт и проверьте именно его, а не только проект в Xcode. Для .pkg выполните тестовую установку на целевой конфигурации macOS. Если выпуск включает приложение, проверьте его подпись и нотариальный статус отдельно; руководство Apple по нотариальной проверке программ macOS перед распространением помогает сверить логику этого этапа.

При проблемах с подписью или нотариальной проверкой не делайте вывод только по одному сообщению сборки. Сопоставьте результат с журналами и рекомендациями Apple по устранению распространённых проблем нотариальной проверки. Метка времени и сертификат — разные части проверки; особенности сертификатов и меток времени Apple разбирает в технической заметке о сертификатах подписи кода.

CI/CD-инженеру: подключите G2 через изолированную задачу

В автоматической сборке миграция часто ломается не при создании нового сертификата, а из-за скрытой ссылки на старую идентичность. Сертификат может быть добавлен на сборочную машину, но задача по-прежнему запрашивает прежнее имя; закрытый ключ может отсутствовать в используемой связке ключей; отдельный шаг публикации может подписывать пакет другим сертификатом, чем приложение.

Поэтому сначала опишите, где и как подписывается каждый выпуск:

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

Затем подключите новый сертификат в отдельной задаче публикации. Она должна собрать реальный тестовый артефакт тем же способом, что и выпуск, но не подменять сразу рабочую цепочку. Проверьте подпись приложения, подпись .pkg, результат нотариальной проверки там, где она предусмотрена, и установку пакета на целевой системе. Только после этого меняйте основную конфигурацию CI.

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

Если команде требуется временный Mac для проверки новой цепочки, сначала оцените доступ к ключам и способ удалённого управления. В материалах ArmMacs о поддержке удалённого Mac можно сверить, какие вопросы по подключению и рабочей среде стоит прояснить до выбора такого узла. Это не заменяет настройку защищённого хранения ключей и не подтверждает совместимость конкретной CI-системы без испытания.

Частые вопросы о сертификате и поставляемых файлах

Как определить, что сертификат относится к старому центру?

Откройте подробные сведения сертификата в связке ключей и проверьте издателя и цепочку. Затем сопоставьте данные с инструкцией Apple по замене Developer ID. Не определяйте статус по одному лишь отображаемому имени, сроку действия или названию сертификата в сценарии сборки: сценарий может ссылаться на прежнюю идентичность, а имя в интерфейсе не показывает всю цепочку. Если сведений недостаточно, выясните статус до публикации, а не после появления проблемы у пользователей.

Чем G2 отличается от старого сертификата в рабочем процессе?

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

Можно ли оставить старый .pkg доступным после срока?

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

Нужно ли повторно подписывать приложение вместе с пакетом?

Не обязательно. Решение зависит от артефакта и его статуса: Apple указывает, что существующие нотарифицированные приложения с безопасной меткой времени продолжат работать, но для затронутых .pkg требуется повторная подпись. В реестре выпуска фиксируйте результат для приложения и пакета отдельно, чтобы успешная проверка одного не скрыла проблему другого. Если приложение поставляется как внутри пакета, так и отдельной загрузкой, проверяйте обе опубликованные копии.

Ответственному за выпуск: назначьте владельцев и условие отката

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

Перед изменением основной задачи используйте этот список приёмки:

• [ ] Зафиксированы все используемые сертификаты Developer ID Application и Developer ID Installer, а также места их использования.
• [ ] Издатель каждого сертификата проверен по сведениям сертификата и официальной процедуре Apple.
• [ ] Подтверждено, что сертификат-замена относится к требуемому типу и доступен нужной сборочной задаче вместе с соответствующим закрытым ключом.
• [ ] Изолированная задача CI собрала тестовый артефакт, подписанный новой идентичностью.
• [ ] Приложение и .pkg проверены раздельно; результат нотариальной проверки приложения учтён там, где она является частью выпуска.
• [ ] Финальный .pkg установлен в тестовой среде, а проверен именно тот файл, который будет опубликован для пользователей.
• [ ] Назначены ответственные за переключение и условие отката: при несовпадении идентичности или неудачной установке выпуск остаётся на проверенной процедуре, а артефакт не объявляется принятым.
• [ ] В плане публикаций отражено требование Apple завершить миграцию затронутых пакетов до 1 февраля 2027 года.
• [ ] После переключения проверено, что расписания и отдельные сценарии выпуска не продолжают использовать прежнюю идентичность.

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

Выбор среды для проверки и переключения

Если подпись выполняется только на собственном Mac, команда сохраняет прямой контроль над устройством и ключами, но сама отвечает за его доступность, обновление и сопровождение. Linux-хост не заменяет macOS для этапов, которым нужны инструменты Apple и проверка поведения подписанного Mac-артефакта. Виртуализированная или непроверенная среда также не должна считаться эквивалентом реальной приёмки только потому, что сценарий сборки завершился без ошибки.

Удалённый Mac может быть полезен как временная среда для тестового выпуска, проверки установки или воспроизведения CI-сценария, если команда может безопасно организовать доступ к ключам и ограничить права. При постоянных тяжёлых задачах, необходимости физического интерфейса или жёстких требованиях к контролю оборудования предпочтительнее оценить собственную машину. Если же нужна временная среда для проверки перехода, изучите планы аренды Mac от ArmMacs и заранее уточните, подходит ли конкретный способ доступа вашим требованиям по секретам и эксплуатации.

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

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