iOS署名証明書ローテーション：2026年CI/CD

証明書の期限が迫っているのに、どのMacで署名しているか、旧Profileを誰が管理しているか分からない状態になっていませんか。

今週やるべきことは、失効を待たずに新しい署名IDを作成し、隔離したMacノードでProfile更新から実際のアップロードまで検証し、切り替え確認後に旧証明書を撤回することです。ただし、秘密鍵の漏えいが疑われる場合は、通常の重複運用よりも封じ込めと緊急撤回を優先します。

この手順は、Apple Developerのアカウント、証明書、Profileを管理するIT担当者向けです。
iOS CI/CD、Keychain、Macビルドノードを維持するプラットフォームエンジニア、リリース切り替えと監査証跡を承認する開発責任者・セキュリティ責任者にも適しています。

SECTION 01 期限切れを待たないための判断基準

今週の判断

[ ] 証明書、秘密鍵、Provisioning Profile、Bundle ID、利用アプリ、利用ノード、責任者を一つの資産台帳にまとめる
[ ] 新しい署名証明書を、Account HolderまたはAdminの承認下で発行する
[ ] 本番とは分離したMacノードで、Archive、署名、Export、アップロードまで確認する
[ ] 新旧の署名経路を比較し、失敗時に旧経路へ戻せる状態を残す
[ ] 全ノードの証明書指紋、秘密鍵の有無、Profileの状態を個別に確認する
[ ] 検証記録と承認記録を保存してから旧証明書の撤回を承認する

通常の有効期限切れでは、先に新しい証明書とProfileを準備し、切り替え後に旧証明書を撤回します。秘密鍵の漏えいが疑われる場合は、この順序を固定してはいけません。漏えいした鍵を使い続ける時間そのものがリスクになるため、影響範囲を記録し、必要な証明書を優先して撤回します。

Appleの公式サポートでは、App Store向けのiOS Distribution証明書が期限切れまたは撤回になっても、Apple Developer Programの有効性が維持されていれば、すでにApp Storeにあるアプリ自体は影響を受けないと説明されています。一方で、該当証明書で新しいアプリやアップデートをアップロードすることはできません。Apple公式の証明書影響説明

SECTION 02 第一歩：誰が発行・承認・撤回を担当するか

iOS署名証明書ローテーションで最初に決めるべきなのは、操作手順ではなく責任の境界です。Appleの組織アカウントでは、Distribution証明書の作成と撤回はAccount HolderまたはAdminが担当します。DeveloperにCIノードから証明書を自由に作成・撤回させる設計は避けてください。Apple Developer Programの役割と権限

次のように、RACIに近い分担を先に文書化します。

Account Holder：組織としての最終承認、重大な撤回判断、契約・アカウント責任
Admin：証明書の作成、撤回、Profile再生成、Apple Developer上の変更操作
CIプラットフォーム担当：Macノード、専用Keychain、秘密鍵、署名設定、ログ管理
リリース担当：Archive、Export、App Store Connectへのアップロード、灰度検証
セキュリティ担当：秘密鍵の保管状態、アクセス履歴、漏えい時の封じ込めと監査
開発責任者：本番切り替え、ロールバック、未解決リスクの受け入れ判断

Appleの証明書概要では、Distribution証明書はチームに属し、チームごとに各タイプを1つだけ作成できる扱いです。したがって、複数の担当者やMacに同じ証明書を配布する場合は、発行数を増やすより、秘密鍵の保管場所とアクセス範囲を管理する必要があります。Apple公式の証明書概要

申請記録には、少なくとも次の項目を残します。

申請者と承認者
証明書名、シリアル番号、指紋
Team IDと用途
関連するBundle IDとアプリ
配置するMacノード
秘密鍵の保管先
更新対象のProfile
旧証明書の撤回予定と撤回承認者

SECTION 03 Apple DeveloperとXcodeの使い分け

Apple Developer上で管理するローカル署名IDと、Xcodeの配布フローで利用できるクラウド管理証明書は、同じ扱いにしない方が安全です。

クラウド管理証明書はApple Developer Programのメンバーシップに関連付けられ、Xcode 13以降のOrganizerによる配布フローで利用できます。Appleの説明では、有効期限の90日前から新しい証明書が自動作成され、Account HolderまたはAdminは手動ローテーションも開始できます。Cloud-managed certificatesの公式説明

判断は次のように分けます。

Xcode Organizer中心の配布：クラウド管理証明書を使えるか確認し、Apple側の自動管理範囲を把握します。
JenkinsなどのMac CIで手動署名：証明書と秘密鍵をビルド環境へ導入する必要があるため、専用Keychainとアクセス制御が必要です。
複数ノードで同じ署名方式を使う：証明書ファイルだけでなく、対応する秘密鍵が各ノードで利用できるか確認します。
監査要件が厳しい環境：誰がいつ署名したか、どの証明書指紋を使ったかをログと成果物から追跡できる方式を優先します。

Xcodeの自動署名はProfile更新を簡単にしますが、CIのすべてのノードで同じ結果になるとは限りません。手動署名を採用する場合は、App ID、証明書、対象デバイス、Profile、Entitlementsの対応関係を明示的に管理します。

SECTION 04 第二歩：CI/CDのKeychainとMacノードを分離する

新しい証明書と秘密鍵は、通常のログイン用Keychainや開発者の個人フォルダに置かず、CI専用Keychain、または同等のアクセス制御を持つ秘密情報管理環境へ導入します。チャット、共有フォルダ、公開リポジトリ、CIログへの配置は避けてください。

確認対象は次の通りです。

署名時に選択される証明書名と指紋
秘密鍵が証明書と対になっているか
ジョブ開始時のKeychain unlock処理
codesignが利用できるアクセス権
証明書ファイルや一時Profileの削除
秘密情報を含むログのマスキング
ジョブ終了後のKeychainロック
ノード再起動後に同じ手順で復旧できるか

注意： 1台のMacでArchiveが成功しても、全ノードのローテーション完了とは判断できません。Macごとに証明書指紋、秘密鍵、Profile、Xcodeの署名設定を確認し、ノード単位の証跡を残してください。

多台数のMacを運用する場合は、ノード名だけでなく、実際に使用した署名IDとProfile UUIDをビルド成果物に記録します。これにより、後からどのノードが旧証明書で署名したかを調べられます。

SECTION 05 Provisioning Profileは証明書と一緒に更新する

CI/CDで署名証明書だけを置き換えると、Profile側が旧証明書を参照したままになることがあります。Appleの公式手順でも、Profileを編集する際にはApp ID、証明書、対象デバイスなどを選択し、生成後にXcodeへダウンロードする流れが示されています。Provisioning Profileの編集・再生成手順

実務では、次の順番で確認します。

新しいApple Distribution証明書を発行します。
証明書と秘密鍵を検証用Macの専用Keychainへ導入します。
対象App ID、Bundle ID、Capabilitiesを確認します。
新しい証明書を参照するDistribution Profileを作成または再生成します。
CIのProfile保存先と参照名を更新します。
xcodebuild archiveでArchiveを作成します。
Export時の署名方式、Team、Entitlementsを確認します。
App Store Connectへのアップロード、または企業内配布用の検証を実行します。
成果物、ログ、証明書指紋、Profile UUIDを保存します。

自動署名ではXcodeがProfileを更新する場合がありますが、Profileが更新されたことをログで確認しないまま本番へ進めるべきではありません。手動署名では、Profileの再生成と各ノードへの配布を明示的な変更として扱います。

SECTION 06 「Apple Distribution証明書を撤回すると既存アプリはどうなるか」

App Store配布の既存アプリと、社内配布アプリは分けて考えます。Appleの公式サポートによれば、App Store上の既存アプリは、メンバーシップが有効であればDistribution証明書の期限切れや撤回だけで影響を受けません。ただし、新しいアプリやアップデートのアップロードはできなくなります。

一方、社内配布用の証明書では、同じ証明書で署名されたアプリの扱いが異なります。社内アプリを運用している場合は、App Store向けの運用と同じ前提で撤回しないでください。

また、Appleは撤回した証明書を含むProvisioning Profileが無効になると説明しています。したがって、旧証明書を撤回する前に新Profileを準備し、撤回後には旧Profileが残っていないか、対象ノードが新Profileを参照しているかを確認します。証明書撤回の公式手順

SECTION 07 第三歩：切り替えを許可する証拠をそろえる

本番切り替えの承認条件は、「新しい証明書が作成された」では不十分です。少なくとも、次の証拠がそろっている必要があります。

新旧証明書の指紋比較
新しい秘密鍵が利用できること
対象Bundle IDとTeam IDの一致
EntitlementsとProfileの一致
Archiveが生成できること
Export後の署名検証が通ること
App Store Connectへのアップロード確認
複数Macノードで同じ結果が得られること
失敗時に旧経路または別の検証ノードへ戻せること
旧証明書を撤回する承認記録

Appleの配布ドキュメントでは、アプリを十分にテストした後、TestFlightやApp Storeへ配布する流れが示されています。企業のCI/CDでも、単なるローカルArchiveではなく、実際の配布経路に近い検証を行うべきです。Xcode配布フローの公式ドキュメント

ここで重要なのは、失敗時の戻し方を先に決めることです。新Profileの読み込みに失敗した場合、旧証明書を即座に削除してしまうと、原因調査と再ビルドを同時に難しくします。通常の期限切れ対応では、切り替え確認後に旧証明書を撤回してください。

SECTION 08 Mac構築方式はどれを選ぶべきか

企業のMac基盤では、主に3つの運用方式があります。

本番ビルドMacを直接変更する

最も手軽ですが、作業中に本番ジョブが旧設定と新設定の混在状態になります。リリースが集中する時期や、同じノードで複数のTeamを扱う場合は、設定ミスの影響範囲が大きくなります。

専用の予備Macで先に検証する

本番ノードを止めずに、証明書、Profile、Keychain、Xcode設定を確認できます。検証後に同じ構成を本番へ反映するため、監査証跡を作りやすい方式です。ただし、予備Macの定期更新、再起動、遠隔復旧、容量確保を自社で維持する必要があります。

短期のリモートMacノードを追加する

期限前のローテーションや、複数アプリの切り替えが重なる時期に、専用の検証環境を一時的に増やせます。自社で物理Macを購入するより準備期間を短くしやすい一方、長期の高負荷ビルドを固定運用する場合は、購入・自社運用・別のクラウド基盤も含めてTCOを比較してください。

既存のXcode環境やクラウド型ビルドとの違いを整理したい場合は、Xcode CloudとiOSビルドサーバーの選び方も確認できます。企業向けの検証ノードを用意する場合は、VPSNIXのMacレンタル料金で契約期間と運用条件を確認し、必要な期間だけ導入する設計にしてください。

SECTION 09 最終承認前のローテーションチェック

[ ] 証明書の種類と用途が資産台帳に登録されている
[ ] Apple DeveloperのAccount HolderまたはAdminが発行を承認している
[ ] CIノードに個人のApple Account認証情報を直接保存していない
[ ] 専用Keychainが作成され、アクセス権が限定されている
[ ] 証明書と秘密鍵の組み合わせを全ノードで確認した
[ ] 新しいProvisioning ProfileをApp IDとEntitlementsに照合した
[ ] XcodeのArchive、Export、アップロードを検証した
[ ] 全Macノードの指紋とProfile UUIDを記録した
[ ] 本番切り替え後の監視担当者を決めた
[ ] 旧証明書を撤回する承認者と実施者を分けた
[ ] 漏えい時に通常手順を中断する連絡経路を用意した
[ ] 撤回後にProfileの再生成とCIキャッシュの更新を確認する

署名証明書の更新だけを目的に見ると、現在の物理Macや共有ビルドサーバーをそのまま使う方が安く見えることがあります。しかし、検証用ノードがなく、Keychainが共有され、再起動後の復旧手順も曖昧な環境では、期限切れや漏えい発生時にリリース停止と緊急対応が重なります。長期の固定負荷なら自社設備が適する場合もありますが、ローテーション期間だけ独立したMac検証環境が必要なら、VPSNIXのMacレンタルを週単位または月単位で追加する方が、既存ノードを直接変更するより安全に切り分けられます。

まずは日本語のVPSNIXサービス案内で、独立したリモートMacノードを検証用に組み込めるかを確認してください。重要なのは、レンタルそのものではなく、証明書発行、Profile更新、実ビルド、撤回、監査記録までを一つの承認可能な運用として完結させることです。