Ротация сертификатов подписи iOS: чек-лист 2026

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

Самое быстрое решение — не ждать отказа: заранее создать новую signing identity, обновить Provisioning Profile на изолированном Mac-узле, проверить полный путь от архива до загрузки и только после этого отзывать старый сертификат; при подозрении на утечку приватного ключа приоритет меняется на немедленное ограничение ущерба и отзыв.

Эта инструкция предназначена для трёх групп:

• администраторов Apple Developer, управляющих сертификатами, ролями и доступом;
• платформенных инженеров, отвечающих за iOS CI/CD, Keychain и Mac-сборочные узлы;
• руководителей разработки и безопасности, которые утверждают переключение, экстренный отзыв и аудиторские доказательства.

SECTION 01 План действий: что сделать на этой неделе

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

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

SECTION 02 Какие границы нужно зафиксировать до начала работ

Ротация сертификатов подписи iOS — это не простая замена файла в секрет-хранилище. Сертификат связан с приватным ключом, Provisioning Profile, App ID, entitlements, Team ID и конкретным поведением CI-инструментов.

Apple указывает, что distribution-сертификаты принадлежат команде, а создавать их могут только Account Holder или Admin. Для каждой команды действует ограничение на один сертификат конкретного distribution-типа, за исключением Developer ID-сертификатов. Поэтому сначала проверьте, какая именно identity используется: Apple Distribution, устаревший тип iOS Distribution, development-сертификат или облачно управляемая identity. Ограничения и назначение типов описаны в официальном обзоре сертификатов Apple.

Инвентаризация сертификатов и профилей

Создайте отдельную таблицу, где одна строка соответствует одной рабочей цепочке подписи:

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

Проверьте также скрытые зависимости:

• несколько Bundle ID в одном архиве;
• расширения приложения и notification service;
• разные профили для development, ad hoc и App Store;
• entitlements, включая push notifications, associated domains и App Groups;
• ручные настройки CODE_SIGN_IDENTITY и PROVISIONING_PROFILE_SPECIFIER;
• секреты, зашитые в переменные CI или временные файлы.

Кто имеет право создавать и отзывать сертификаты

Account Holder отвечает за владельца учётной записи, соглашения и назначение администраторов. Admin получает расширенные полномочия по управлению сертификатами и профилями. Developer не должен автоматически получать доступ к созданию или отзыву distribution-сертификатов только потому, что он запускает сборки.

В таблице ролей Apple Developer отдельно указаны права на создание и отзыв distribution-сертификатов, создание Provisioning Profile и доступ к Certificates, Identifiers & Profiles. Используйте её как источник для своей RACI-матрицы, но не подменяйте официальные полномочия внутренней должностной инструкцией.

Минимальная RACI-модель выглядит так:

• Account Holder/Admin — создаёт или отзывает distribution-сертификат;
• IT-администратор — ведёт реестр, согласование и сроки;
• CI-платформа — импортирует identity в контролируемое окружение;
• релизная команда — запускает архивирование, экспорт и загрузку;
• безопасность — подтверждает обращение с приватным ключом и решение об отзыве;
• технический руководитель — утверждает переход в production.

Запись согласования должна содержать заявителя, отпечаток сертификата, Team ID, назначение, связанные приложения, узлы, дату планируемого переключения и объект последующего отзыва.

SECTION 03 Как обновить подпись без разрыва CI/CD

Создание новой identity и выбор модели управления

Сначала решите, где будет находиться приватный ключ.

При локальном управлении новая identity импортируется в выделенный Keychain каждого нужного Mac-узла. Это подходит, если компания контролирует процесс выпуска, использует ручную подпись или внешний CI-сервер. При облачном управлении Xcode может использовать cloud-managed certificates в поддерживаемом сценарии; Apple указывает, что такие сертификаты связаны с членством Apple Developer и управляются удалённо. Account Holder и Admin могут инициировать их ротацию, а автоматическое создание нового сертификата выполняется заранее до истечения срока в соответствующем cloud-сценарии. Точные ограничения зависят от процесса подписи и версии Xcode, поэтому их нужно проверить в документации Apple о cloud-managed certificates.

Не переносите Apple Account с административными полномочиями на CI-узел. CI должен получать только необходимые signing assets или ограниченный механизм доступа, а операция создания и отзыва должна оставаться за контролируемым человеком или отдельным процессом управления.

Как обновляется Provisioning Profile

Если сертификат подписи заменён, нужно ли обновлять Provisioning Profile?

Да, если профиль содержит старый сертификат или после отзыва старого сертификата становится недействительным. В профиле указываются App ID и distribution-сертификат; после отзыва сертификата профили, которые его содержат, становятся недействительными. Профиль нужно отредактировать или сгенерировать заново, а затем скачать в Xcode или через учётную запись. Порядок действий описан в официальной инструкции Apple по управлению Provisioning Profile.

Порядок действий:

1. Откройте Certificates, Identifiers & Profiles.
2. Проверьте App ID, для которого создаётся профиль.
3. Выберите новый distribution-сертификат.
4. Убедитесь, что capabilities и entitlements соответствуют проекту.
5. Сгенерируйте новый профиль с отличимым именем.
6. Скачайте его в CI-секретохранилище или установите на нужный Mac.
7. Удалите из рабочего маршрута старый профиль, но сохраните его копию для аудита.
8. Проверьте, что Xcode не использует устаревший локальный кэш.

При автоматической подписи Xcode может самостоятельно запросить профиль, если не находит локальный вариант, удовлетворяющий требованиям. При ручной подписи лучше явно закрепить имя профиля и проверять его содержимое в pipeline, чтобы обновление не осталось незаметным. При проверке настроек проекта используйте также официальную документацию Apple о настройке signing для Xcode, особенно если часть targets подписывается автоматически, а часть — вручную.

Как изолировать Keychain и Mac-узлы

Новый сертификат и приватный ключ должны попадать только в выделенный CI Keychain либо в эквивалентную систему с контролем доступа. Не передавайте .p12 и пароль через чат, общую папку или публичный каталог. Тот, кто получит экспортированную signing identity и пароль, сможет распространять программное обеспечение от имени вашей команды. Экспортированную identity следует защищать сильным паролем, а файл и пароль передавать по разным контролируемым каналам.

На каждом Mac-узле проверьте отдельно:

• сертификат присутствует в нужном Keychain;
• приватный ключ связан именно с новым сертификатом;
• CI-пользователь может разблокировать Keychain без интерактивного диалога;
• ACL не разрешает доступ посторонним процессам;
• переменные с паролями не выводятся в логи;
• временные .p12, профили и архивы удаляются после job;
• после перезапуска узла цепочка восстанавливается предсказуемо;
• выбранная signing identity совпадает с ожидаемым типом сертификата.

SECTION 04 Как доказать, что новая цепочка действительно готова

Успешная сборка на одном Mac не подтверждает готовность всей фермы. Многопоточность CI, разные версии Xcode, локальные кэши и различия в Keychain часто скрывают проблему до первого production-запуска.

Проверку выполняйте на независимом или неприоритетном узле:

1. очистите рабочую директорию и локальные артефакты подписи;
2. установите новый профиль и новую identity;
3. выполните архивирование проекта;
4. проверьте подпись архива;
5. экспортируйте приложение с тем же методом, который используется в production;
6. проверьте Bundle ID, Team ID и entitlements;
7. выполните тестовую загрузку в App Store Connect либо другой предусмотренный канал;
8. сохраните номер сборки, отпечаток сертификата, профиль и логи без секретов;
9. повторите проверку на каждом Mac-узле, который может принять production job;
10. выполните пробный запуск после перезагрузки узла.

Как синхронизировать новый сертификат на нескольких Mac-сборочных машинах?

Не копируйте только файл сертификата. На каждом узле должна появиться полная связка сертификата и приватного ключа, новый Provisioning Profile, одинаковые параметры выбора identity и подтверждённый доступ CI-пользователя к Keychain. Сравнивайте отпечаток сертификата, наличие приватного ключа и статус профиля отдельно для каждой машины.

Соберите доказательства в виде:

• списка узлов и времени проверки;
• отпечатка новой identity;
• результата команды проверки подписи;
• имени использованного профиля;
• результата archive/export/upload;
• записи о перезапуске и восстановлении Keychain;
• ответственного инженера и отметки руководителя релиза.

SECTION 05 Когда старый сертификат можно отозвать

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

• новая identity присутствует на всех разрешённых production-узлах;
• профиль обновлён для каждого затронутого App ID;
• полный релизный путь успешно проверен и существует понятный план возврата.

Повлияет ли отзыв Apple Distribution-сертификата на приложение, уже размещённое в App Store?

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

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

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

SECTION 06 Итоговая приёмка перед production-переключением

Используйте этот список как обязательное условие передачи между ролями:

• [ ] Для каждого сертификата указаны тип, Team ID, отпечаток и владелец.
• [ ] Определены все приложения, расширения, Bundle ID и связанные профили.
• [ ] Создание новой distribution identity выполнил Account Holder или Admin.
• [ ] Решение о создании содержит заявителя, назначение и план отзыва старого объекта.
• [ ] Приватный ключ импортирован только в выделенный CI Keychain или контролируемое хранилище.
• [ ] Пароль от экспортированной identity не передавался вместе с файлом.
• [ ] На каждом Mac-узле найден новый сертификат.
• [ ] На каждом Mac-узле присутствует соответствующий приватный ключ.
• [ ] На каждом узле установлен актуальный Provisioning Profile.
• [ ] Xcode и CI используют ожидаемые signing identity и профиль.
• [ ] Проверены Bundle ID, Team ID и entitlements.
• [ ] Выполнены archive, export и тестовая загрузка.
• [ ] Логи очищены от паролей, токенов и содержимого секретов.
• [ ] Проверено восстановление Keychain после перезапуска узла.
• [ ] Подготовлен откат на предыдущую рабочую конфигурацию.
• [ ] Старый сертификат ещё не отозван до завершения всей проверки.
• [ ] При признаках утечки запущен отдельный аварийный процесс отзыва.
• [ ] Руководитель релиза и безопасность подписали результат приёмки.

Для резервного контура заранее определите, где будет находиться независимый Mac-узел и кто имеет право его восстановить. Если в вашей инфраструктуре нет изолированного тестового Mac, root-доступа, удалённого перезапуска или возможности быстро добавить временную мощность, это уже не только проблема сертификатов — это ограничение всей модели выпуска.

Собственный Mac mini может быть оправдан для постоянной нагрузки и требований к физическим интерфейсам, но для корпоративной ротации он часто создаёт дополнительные обязанности: закупка, доставка, запасное оборудование, удалённое восстановление, контроль доступа и простой при аппаратных работах. Публичная виртуальная среда, в свою очередь, не заменяет настоящий Mac для задач, где нужны macOS, Xcode и Apple signing toolchain. Если вам требуется временный изолированный узел для проверки сертификатов, резервный CI-контур или сезонное расширение сборочной мощности, аренда Mac через тарифы VPSNIX позволяет сначала проверить процесс на выделенной машине, а не менять всю инфраструктуру закупками. Перед заказом проверьте, подходят ли вам период аренды, модель удалённого доступа и требования к постоянному хранению секретов; для долгосрочной непрерывной нагрузки и физического оборудования покупка собственного Mac может оказаться рациональнее.

Если тестовый узел нужен уже сейчас, изучите варианты заказа удалённого Mac через VPSNIX и включите его в план как отдельную проверочную среду, а не как замену контролям Apple Developer. Финальное решение должно приниматься по доказательствам: новая подпись работает, профиль соответствует приложению, каждый узел проверен, а старый сертификат отзывается только после утверждённой передачи.

Дополнительно

• Xcode Cloud или собственный сервер сборки iOS: выбор модели CI/CD в 2026 году
• Аренда Mac mini M4 для iOS CI/CD: цены, безопасность ключей и проверка провайдера
• Арендовать или купить Mac mini M4 для сборочного узла: расчёт затрат в 2026 году