署名エラーでリリースが止まり、証明書を入れ替えるだけで直るのか判断できない状態です。
企業iOS CI証明書のローテーションは、証明書の種類とApple Developerアカウントの制約を確認し、関連するProvisioning Profileを更新してから、隔離Macで署名から配布まで検証します。合格後に本番へ切り替え、旧証明書を適切に処置してください。秘密鍵の漏えいが疑われる場合は、通常の切替計画より緊急対応を優先します。
Apple Developerアカウントと署名資産を管理するIT担当者向けです。
iOS CI/CDを運用するプラットフォームチームや、リリース・セキュリティの責任者にも役立ちます。
[ SECTION_01 ] 作業前の資産棚卸し
「証明書」という名前だけで作業を始めると、開発用と配布用の署名資産を取り違えることがあります。Appleは用途の異なる証明書を案内しているため、まず対象のアプリ、署名方式、証明書の種類を記録します。Appleの証明書一覧と用途で該当する種類を確認してください。
代表的な区別は次のとおりです。Apple DistributionはAppleのプラットフォーム向けアプリ配布、開発証明書は開発時の署名、Developer IDはMacアプリの配布に関係します。クラウド管理証明書は別の管理方式です。名称が似ていても同じ手順を当てはめず、対象環境とアカウント上の状態を照合します。
次に、影響範囲を一覧にします。少なくとも対象App ID、利用中の証明書と秘密鍵の保管場所、Provisioning Profile、署名を実行するMac CIノード、関連するビルド・配布ジョブを記録してください。秘密鍵と証明書は別の資産として扱い、どのアカウントやCI実行環境からアクセスできるかも明記します。
基準となるのは、推測した「通常の成功経路」ではありません。直近に成功したビルドと配布のログ、Apple Developerアカウントの表示、実際のノード上の署名設定を照合し、現在の状態を記録します。責任者、変更承認、切替後の停止条件、旧経路へ戻す条件も事前に決めておきます。
[ SECTION_02 ] 交換用署名資産の準備
新しい証明書を作成する前に、Apple Developerアカウントで作成・管理・撤回を行える権限があるか確認します。役割ごとに利用できる機能が異なるため、担当者の権限はApple Developer Programの役割とアクセス権で照合してください。権限不足のまま変更日を迎えると、承認待ちで切替作業が止まるおそれがあります。
発行・管理の方法は証明書の種類とアカウントの状態で異なります。クラウド管理証明書を使う構成では、通常の証明書と同じ方法で秘密鍵を配布する前提にせず、クラウド管理証明書の利用と更新手順を確認します。作成できる数や同時に扱える状態を全チーム共通の固定条件として決めつけず、アカウント画面と該当する証明書のルールを照合してください。
新しい秘密鍵を発行する場合は、生成場所、保管先、アクセスできる担当者、CIノードへの受け渡し方法を記録します。開発者全員へ鍵を配るのではなく、署名に必要な権限と保管経路を限定します。新旧証明書を並行して検証できると決めつけることも避けてください。アカウントの状態や証明書の種類によって並行運用が成立しない場合は、検証用の変更窓と停止条件を設定します。
秘密鍵の漏えいが疑われる場合は、通常の更新手順を完了するまで撤回を保留しないでください。失効による影響を確認しながら、社内のインシデント対応責任者とAppleの手順に沿って対処します。
[ SECTION_03 ] Provisioning Profileの更新
証明書を差し替えても、関連するProvisioning Profileが新しい署名資産に合っているとは限りません。プロファイルが対象App IDや利用する署名証明書と対応しているかを点検し、必要な場合は更新または再生成します。App Store向けProvisioning Profileの作成条件を参照し、対象アプリに使う設定と照らし合わせてください。
手動署名では、更新したプロファイルをダウンロードし、CIノードの適切な実行環境へ反映したうえで、ジョブがそのファイルを参照することを確かめます。Xcode管理のプロファイルでは、Xcodeが選んだプロファイルと署名証明書をビルドログで確認します。Keychainに新証明書を追加しただけで作業完了にせず、古いプロファイルが残っていないかも調べます。
既存プロファイルを編集、ダウンロード、再生成する選択肢は、プロファイルの種類と変更内容によって異なります。プロファイルの編集・ダウンロード・削除の説明とプロファイル更新時の扱いを確認し、変更後の設定がCIで実際に読み込まれた証拠を残してください。
[ SECTION_04 ] 隔離Macでの署名・配布検証
既存の本番ジョブを直接書き換えず、切り離したMac CIノードまたは独立した検証ジョブで確認します。検証対象には、署名証明書の読み込みだけでなく、アーカイブ作成、エクスポート、実際に利用する配布経路まで含めます。アプリや配布方式に応じて、成功とみなす条件を事前に決めてください。
確認では、ビルドログと署名結果に旧証明書や古いプロファイルが残っていないかを見ます。App ID、署名証明書、プロファイル、CIノードの実行権限、配布に必要な資格情報をひとまとまりで照合します。ビルドだけが成功しても、エクスポートや提出の段階で旧資産を参照していれば本番切替の合格とはしません。
本番移行の承認条件は、検証結果、変更記録、承認者、失敗時の停止・復旧条件が追跡できることです。署名だけ通った状態や、担当者の手元で一度成功した状態を合格扱いにせず、対象のCI経路で再現できることを確認します。
[ SECTION_05 ] 本番切替と旧証明書の処置
対象アプリやCIジョブを単位に段階的に切り替え、各段階で署名と配布の結果を確認します。失敗が出た場合は、事前に定義した停止条件に従って後続の切替を止め、ログから証明書、プロファイル、ノード設定のどこで不一致が起きたかを調べます。新しい資産で本番経路が安定した後に、旧証明書・秘密鍵・キャッシュされたプロファイルの処置へ進みます。
旧証明書を撤回する前には、その証明書を使うアプリ、ジョブ、プロファイルが残っていないかを再点検します。Appleは証明書の撤回による影響を案内しており、関連プロファイルへの影響は証明書の種類や使用状況を踏まえて確認する必要があります。証明書を撤回する際の影響と手順および権限撤回に関する説明に従い、撤回後に必要なプロファイルの修復と再検証を行ってください。
[ SECTION_06 ] 切替前の実行チェックリスト
- [ ] 対象アプリ、App ID、署名方式、証明書の種類を記録した
- [ ] Apple Developerアカウントの状態と担当者の権限を確認した
- [ ] 秘密鍵の保管場所とアクセス範囲を確認し、変更を記録した
- [ ] 既存のProvisioning Profileと新しい署名資産の対応を確認した
- [ ] 隔離したMac CIノードで署名から配布まで検証した
- [ ] ログで旧資産の参照が残っていないことを確認した
- [ ] 本番切替の停止条件、復旧手順、旧証明書の処置を承認済みにした
以下はAppleの保証評価ではなく、作業経路を選ぶための運用上の目安です。特に、証明書の種類やアカウント状態が未確認なら、切替の準備より先に棚卸しへ戻ります。
| 状況 | 選ぶ作業経路 | 判定 |
|---|---|---|
| 種類・権限・プロファイルの対応が確認でき、隔離ノードで全経路を検証できる | 検証後に対象ジョブから段階切替 | 適合 |
| 新旧資産を並行検証できるか、アカウント上で確認できていない | Appleの該当ルールとアカウント状態を確認し、変更窓を設定 | 要確認 |
| 秘密鍵漏えいの疑いがある | 通常の切替待ちにせず、緊急撤回と影響確認を実施 | 緊急対応 |
| 署名は成功するが、配布またはエクスポートを検証していない | 本番切替を保留し、隔離環境で残りの経路を検証 | 未合格 |
[ SECTION_07 ] よくある質問
期限切れで止まったCIは、証明書だけ更新すれば復旧できますか。
証明書の状態だけでなく、対応するプロファイル、ノードの署名設定、配布工程も確認します。利用中の証明書を更新できる権限があることを確かめ、現在の署名資産に合うプロファイルを準備してから、隔離ノードで配布経路まで検証してください。
Apple Distribution証明書の変更後、プロファイルの再生成が必要ですか。
新証明書が対象のプロファイルに含まれているかを確認して判断します。対象外なら、プロファイルを編集または再生成し、CIノードへ反映します。Xcode管理の場合も、自動選択されたプロファイルと証明書の組み合わせをログで確認します。
本番への影響を抑えて新証明書を試すにはどうしますか。
本番ジョブの設定を直接上書きせず、隔離したMac CIノードで独立した検証を実行します。代表的なアプリで署名、アーカイブ、エクスポート、配布を確認し、結果とログを保存してから本番移行の承認を得ます。
秘密鍵の漏えいが疑われる場合、切替完了まで撤回を待つべきですか。
いいえ。漏えいの疑いがある場合は、通常のローテーション日程を優先して撤回を遅らせず、セキュリティインシデントとして対応します。撤回の影響範囲を確認し、関連プロファイルとCIジョブを修復したうえで、新しい署名資産によるリリース経路を検証してください。
[ SECTION_08 ] 署名検証用Mac環境の選択
既存の社内Macを使う場合、調達費だけでなく、保守担当の確保、検証環境の分離、使わない期間の設備負担も考慮が必要です。共有ノードのまま署名資産を扱うと、アクセス権やキャッシュの整理が不十分な場合に、誰がどの鍵を使ったか追いにくくなります。購入を検討する場合は、日本向けMac miniの構成情報も確認し、自社保有に必要な運用負担を含めて比較してください。
一方、署名輪換の試験環境だけが必要なチームには、常時稼働の実機を購入する方法が過剰になることがあります。リモートMacを使う場合も、秘密鍵を置く位置、利用者の権限、ログの保管、インシデント時の対応を先に決めることが前提です。検証環境や一時的なCIノードを調達する選択肢として、実機Macを週・月・四半期単位で利用できるNOVAKVMのMac環境を確認し、社内のセキュリティ要件を満たす用途に限って試験導入を評価してください。
よくある質問
期限切れの署名証明書が原因で、iOS CIのリリースが止まった場合はどう復旧しますか？
まず証明書の種類、Apple Developerアカウントの状態、失敗した署名工程を確認します。新しい証明書を用意できる権限があるかを確認し、対象アプリのProvisioning Profileを現在の署名資産に合わせて更新します。隔離したMac CIノードでアーカイブ、署名、エクスポート、配布先への提出まで通し、成功を確認してから本番ジョブへ反映してください。
Apple Distribution証明書を替えたら、Provisioning Profileも作り直す必要がありますか？
一律に作り直すとは限りません。App Store向けプロファイルがどのApp IDと証明書に対応しているかを確認し、新証明書が対象に含まれない場合は編集または再生成してダウンロードします。Xcode管理の署名を使う場合も、ビルドノードで実際に選択されたプロファイルと証明書の組み合わせを確認してください。
新しい証明書を本番に適用する前に、正式リリースへ影響させず検証できますか？
本番のリリースジョブや既存の署名資産を上書きせず、分離したMac CIノードと検証用ジョブで確認します。代表的なアプリを使い、証明書の読み込み、署名、アーカイブ、エクスポート、配布経路の結果を記録します。ログに旧証明書や古いプロファイルが残っていないことも確認し、承認後に本番へ段階的に反映します。
証明書の秘密鍵が漏れた疑いがある場合、流水線の切替と証明書の撤回のどちらを先にしますか？
漏えいの疑いがあるなら、通常の計画的なローテーションとは別のセキュリティインシデントとして扱います。切替の準備が整うまで撤回を遅らせず、Appleの手順と社内のインシデント対応に従って失効影響を確認します。失効後は関連プロファイルと配布経路を点検し、安全な新しい署名資産で再検証してください。