Что делать, если сертификат Developer ID истекает в 2027 году? Чек-лист миграции на 2026 год

Сначала проверьте, выдан ли сертификат Developer ID старым промежуточным центром; затем отдельно оцените приложения macOS и пакеты .pkg. Пакет .pkg, подписанный затронутым сертификатом, следует переподписать до 1 февраля 2027 года. Уже подписанное, нотариально заверенное и снабжённое безопасной меткой времени приложение не нужно переподписывать только из-за истечения этого сертификата; для последующих обновлений потребуется новая подпись. Именно такую границу между пакетами и приложениями проводит объявление Apple об истечении старого Developer ID Sub-CA.

Материал предназначен разработчикам, которые распространяют собственные приложения для macOS и используют Developer ID Application.
Он поможет командам, подписывающим установщики Developer ID Installer, спланировать переподпись и проверку пакетов.
Отдельные рекомендации посвящены удалённым сборочным машинам: новая подпись должна работать в контексте пользователя, который фактически выпускает продукт.

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

Срок сертификата — не единственный критерий

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

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

Как понять, выдан ли сертификат старым Sub-CA? Откройте Certificates, Identifiers & Profiles в учётной записи разработчика и найдите запись сертификата Developer ID. Сопоставьте дату действия и сведения о выдающей стороне с разъяснением Apple о промежуточном сертификате. Затем свяжите эту запись с идентификатором подписи, которым фактически подписаны приложение или установщик. Apple отдельно описывает сведения о старом промежуточном сертификате и его влиянии.

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

Приложение и .pkg: разные последствия одной цепочки

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

Нужно ли повторно подписывать уже нотариально заверенное приложение с безопасной меткой времени? Только из-за истечения старого Sub-CA — нет. Речь идёт о выпущенном приложении, которое подписано, нотариально заверено и имеет безопасную метку времени. Apple указывает, что такое существующее программное обеспечение может продолжить работу, а для последующих обновлений следует использовать новый сертификат. Это не является общей гарантией для любого файла, незавершённого выпуска или способа распространения. Границы этого правила указаны в объявлении Apple, приведённом выше.

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

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

Когда переподписывать установщик? Если проверка показывает, что пакет подписан затронутым Developer ID Installer, подготовьте новую подпись и проверенную замену до 1 февраля 2027 года. Эту дату и последствие для установки подтверждает указанное выше объявление Apple. Проверяйте каждый распространяемый .pkg отдельно: старый установщик может оставаться в архиве релиза, на внутреннем сервере загрузки или в механизме автоматического обновления, даже если основная ссылка уже заменена.

Приёмка нового сертификата: сертификат не заменяет закрытый ключ

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

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

Для первичной инвентаризации на Mac можно выполнить команды ниже. Замените пути на собственные. Команды не передают закрытый ключ:

security find-identity -v -p codesigning
codesign -dv --verbose=4 "/path/to/YourApp.app" 2>&1
pkgutil --check-signature "/path/to/YourInstaller.pkg"

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

Ниже показана схема фрагмента вывода, а не результат проверки конкретной машины:

Authority=Developer ID Application: ...
Timestamp=...

Для пакета команда pkgutil должна показать результат проверки подписи и сведения о подписавшей стороне. Если подпись отсутствует, недействительна или не соответствует ожидаемому сертификату, выпуск следует остановить и выяснить причину. Фраза «сертификат создан» не заменяет проверку пакета, который команда собирается распространить.

Проверка выпуска: шесть контрольных показателей

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

1. Составьте перечень релизных файлов. Запишите распространяемые приложения, установщики, архивы прошлых версий и каналы, из которых пользователи могут получить пакет. Отметьте, что подписано Developer ID Application, а что — Developer ID Installer. Одного исходного проекта недостаточно: он не подтверждает подпись готового файла.

2. Свяжите каждый файл с конкретным сертификатом. Сверьте сведения о подписи с записями в учётной записи. Зафиксируйте используемую цепочку и проверьте, относится ли она к затронутой группе. Если выпуск включает приложение внутри .pkg, проверяйте оба уровня отдельно: корректная подпись пакета не подтверждает корректность подписи приложения.

3. Проверьте новый сертификат в контексте сборки. Убедитесь, что сертификат и закрытый ключ доступны не только интерактивному пользователю, но и учётной записи, запускающей задачу. Зафиксируйте идентификатор подписи и результат проверки Keychain, не сохраняя секретный материал. На удалённой машине дополнительно проверьте, что задача не выбирает старую идентичность из сохранённых настроек.

4. Создайте пробный выпуск и проверьте цели по отдельности. Для приложения проверьте подпись итогового .app и выполните предусмотренную процессом проверку нотариального заверения. Для .pkg проверьте подпись самого пакета и установите его в контролируемой тестовой среде. Успешное создание файла не доказывает возможность его установки. При ошибке нотариального заверения проверьте журнал по рекомендациям Apple по устранению распространённых проблем нотариального заверения.

5. Повторите реальный маршрут публикации. Запустите выпуск тем же способом, которым пользуется команда: вручную, автоматически или на удалённом Mac. Сравните подпись до загрузки и после получения файла из канала распространения. Убедитесь, что замена доступна во всех используемых местах, включая внутренние загрузки и ссылки внутри приложения.

6. Зафиксируйте решение и его доказательства. Для каждого файла выберите действие: оставить без изменения на основании подтверждённых условий Apple; подписывать последующие обновления новым сертификатом; заменить затронутый .pkg и провести приёмку. К решению приложите запись сертификата, результат проверки подписи и, где необходимо, результат установки или нотариального заверения. Так можно отличить обоснованное сохранение старого приложения от пропущенного установщика.

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

Удалённый Mac: проверьте пользователя и путь к артефакту

На удалённой машине учитывайте пользователя процесса, состояние Keychain и способ передачи файла. Администратор может видеть сертификат в собственном сеансе, но автоматическая задача запускается от другой учётной записи и не имеет доступа к той же идентичности. Возможна и обратная ошибка: новый сертификат уже импортирован, но сборка по-прежнему выбирает старый. Фиксируйте не только наличие сертификата, но и идентификатор, которым фактически подписан файл.

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

Для отдельной сборочной машины сравните обслуживание собственной среды с удалённым доступом до переноса ключей. В описании вариантов аренды Mac можно проверить, подходит ли такой формат вашему процессу. Страница SFTPMAC поможет оценить удалённую машину как отдельную macOS-среду. Ни один вариант не отменяет проверки прав доступа, хранения ключей и правил передачи релизных файлов.

Решение по артефакту, а не по названию сертификата

Матрица даёт три разных решения. Старое приложение можно оставить, если для него подтверждены описанные Apple условия. Новую версию следует проверять с новой подписью и полным циклом выпуска. Для затронутого .pkg нужны новая подпись и проверка фактической установки.

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

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

Локальный Mac подойдёт, если команда контролирует хранение ключей, доступ пользователей и регулярную проверку выпуска. Удалённая среда может быть удобна для отдельной сборки и подписания, но у неё есть ограничения: доступ зависит от сети, секреты нужно передавать и хранить безопасно, а состояние Keychain может различаться между интерактивным сеансом и автоматической задачей. Если при миграции требуется отдельная управляемая среда macOS, изучите варианты SFTPMAC и заранее сопоставьте их с требованиями процесса. Если критичны физические интерфейсы или подпись должна работать без сетевой зависимости, собственный Mac может быть предпочтительнее.