Истечение сертификата Developer ID: как перенести Mac CI? 2026

Сначала проверьте издателя сертификатов Developer ID Application и Developer ID Installer, затем подготовьте замену, выданную через G2 Sub-CA, и испытайте её в изолированном Mac CI. Apple сообщает, что после 1 февраля 2027 года подписанные сертификатами старого Sub-CA пакеты pkg не будут устанавливаться, тогда как ранее нотариально заверенные приложения с защищённой меткой времени продолжат работать (объявление Apple).

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

Последняя проверка: 4 октября 2026 года; сведения о сроке действия и границах влияния сверены с объявлением Apple и инструкцией по замене сертификатов Developer ID.

До переключения: соберите карту подписи

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

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

В реестре зафиксируйте:

• тип сертификата: Developer ID Application или Developer ID Installer;
• отображаемое имя, серийный номер и издателя из свойств сертификата;
• Mac CI-узел и учётную запись процесса, которому доступна идентичность;
• задания, сценарии и ветки выпуска, использующие сертификат;
• тип артефакта: приложение, архив либо pkg;
• расположение сертификата и приватного ключа, а также ответственного за доступ;
• факт нотариального заверения приложения и наличие защищённой метки времени, если это подтверждается журналами выпуска.

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

Для понимания назначения сертификатов используйте официальное описание типов сертификатов Apple. Developer ID Application применяется при подписании приложения для распространения вне App Store; Developer ID Installer предназначен для подписи установочных пакетов. Это не одно и то же, и наличие одного типа не заменяет другой.

Определите влияние: сравните издателя и назначение

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

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

Параллельно классифицируйте артефакты по последствиям:

• Уже выпущенное приложение. Если оно нотариально заверено и подписано с защищённой меткой времени, Apple сообщает, что такое ранее выпущенное ПО продолжит работать. Сохраните подтверждение заверения и записи о подписи, чтобы команда могла проверить статус конкретного релиза.
• Будущее обновление приложения. Для последующих выпусков необходимы новый подходящий сертификат и требуемая защищённая метка времени. Поэтому факт, что установленная версия продолжает открываться, не подтверждает готовность CI к следующему релизу.
• Установочный пакет pkg. Согласно объявлению Apple, пакеты, подписанные сертификатами Developer ID Installer, выданными старым Sub-CA, после указанной даты не будут устанавливаться. Проверяйте именно установку собранного пакета, а не только вывод команды подписи.
• Смешанные конвейеры. Если один процесс подписывает приложение, а другой упаковывает и подписывает pkg, назначьте владельца проверки для каждого этапа. Иначе замена одного сертификата может оставить второй этап без исправления.

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

Подготовьте замену и ограничьте доступ к ключу

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

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

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

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

Испытайте обе подписи на изолированном узле

Новый сертификат сначала проверяют в среде, не влияющей на производственный выпуск. Изолированное тестирование должно воспроизводить настройки CI: тот же тип задания, ту же учётную запись сервиса и тот же способ обращения к Keychain. Ручная подпись под администраторской учётной записью не доказывает, что рабочий агент сможет получить доступ к идентичности.

Для приложения проверьте следующие условия:

• CI видит ожидаемый сертификат и соответствующий приватный ключ;
• под рабочей учётной записью выполняется подпись собранного приложения;
• результат проверки подписи соответствует выбранному сертификату;
• приложение проходит отправку и нотариальное заверение;
• итоговый артефакт и сведения о защищённой метке времени сохраняются вместе с журналом выпуска.

Для pkg отдельно подтвердите, что CI использует Developer ID Installer с ожидаемым издателем, пакет подписывается, а его установка проходит на целевой тестовой системе. Если в организации есть несколько способов доставки пакета, воспроизведите каждый используемый путь. Успешный статус подписи сам по себе не является подтверждением установки или корректного поведения после неё.

Сохраняйте логи команд подписи и проверки, сведения о выбранной идентичности, результат notarization и факт установки пакета. Уберите из журналов секреты и приватные данные. Запись должна позволять другому ответственному воспроизвести результат и понять, какая версия конвейера и какой сертификат использовались.

Частые вопросы о замене Developer ID

Как отличить сертификат старого Sub-CA от нового?
Сравните издателя в свойствах сертификата с указаниями Apple и перепроверьте его в аккаунте разработчика. Не полагайтесь только на название или дату окончания. Сделайте отдельные записи для Developer ID Application и Developer ID Installer: сертификат для подписи приложения не подтверждает состояние сертификата, применяемого к pkg.

Нужно ли заново подписывать приложение, уже прошедшее нотариальное заверение?
Apple указывает, что ранее выпущенное нотариально заверенное ПО с защищённой меткой времени продолжит работать. Для будущих обновлений это исключение не отменяет требования перейти на новый сертификат и включить требуемую метку времени. Статус старого выпуска и готовность новой сборки следует проверять отдельно.

Что будет с pkg, если он подписан сертификатом старого Sub-CA?
Apple предупреждает, что после 1 февраля 2027 года затронутые установочные пакеты не будут устанавливаться (объявление Apple). Поэтому проведите проверку до этой даты: подпишите пакет заменой, установите его в тестовой среде и сохраните подтверждающие логи. Проверка лишь команды подписи не выявляет все проблемы установки.

Как выполнить замену без остановки выпуска?
Настройте новую идентичность в изолированном конвейере, не изменяя сразу производственные задания. Сравните результаты подписи приложения и pkg, проверьте notarization и фактическую установку, затем переводите задачи на замену партиями. Откат должен вести к проверенной конфигурации; он не должен зависеть от возможности продолжить подпись сертификатом, который перестанет работать.

Переключите производство партиями и определите условия возврата

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

Не считайте замену завершённой только потому, что сборка зелёная. Перед расширением переключения убедитесь, что новая идентичность действительно использовалась, приложение прошло проверку и заверение, а pkg успешно подписан и установлен. Также проверьте, что старый сертификат больше не используется скрытой веткой, ночным заданием или отдельным сценарием публикации.

Условия возврата задайте заранее. Если новая конфигурация не обеспечивает подпись либо ломает доставку артефакта, остановите дальнейший перевод и верните задание на последнюю проверенную конфигурацию, одновременно устранив проблему в изолированной среде. Не планируйте возврат, который предполагает продолжение подписи сертификатом старого Sub-CA после окончания его действия: такой сценарий не является надёжным способом восстановления.

Для принятия решения используйте следующие ветви:

• Если издатель сертификата подтверждает, что он выдан старым Sub-CA, включите связанные задачи и артефакты в план миграции; если издатель не проверен, сначала остановите выводы и завершите сверку.
• Если используется Developer ID Installer и задача выпускает pkg, требуйте испытания установки пакета с заменой; если в цепочке есть только подпись приложения, не считайте проверку приложения заменой теста pkg.
• Если новый сертификат доступен процессу CI, но не проверен в реальном релизном маршруте, оставьте его в тестовой среде; если подпись, заверение и доставка подтверждены, допускайте ограниченное переключение.
• Если пакет или приложение не проходят проверку, остановите расширение миграции и исправьте её причину; не закрывайте инцидент успешной сборкой другого типа артефакта.

Перед допуском к релизу: проверьте доказательства и инфраструктуру

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

Для команд, которым нужен отдельный Mac CI-узел, отдельно оцените способ изоляции учётной записи подписи, хранения ключа, журналирования и доступа к тестовым артефактам. Это решение не заменяет управление сертификатами: выделенный компьютер не исправит неверно выбранный тип Developer ID, а новый сертификат не устранит чрезмерные права процесса CI.

Если команда выбирает собственный Mac, она сохраняет контроль над оборудованием, но принимает на себя закупку, обслуживание, обновление и планирование простаивающей мощности. Если рассматривается временная удалённая среда, заранее подтвердите, что способ выдачи доступа и правила работы с секретами подходят внутренним требованиям. Актуальные коммерческие условия RUVCLOUD можно сверить на странице тарифов, а доступные варианты размещения и оформления заказа — на странице заказа удалённого Mac. Конкретные конфигурации, сроки предоставления и возможности следует подтверждать по фактическим условиям, а не предполагать по описанию миграции.

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

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