Developer ID G1の期限切れ、Macインストーラ署名の移行方法？2026

先に判断：期限より署名チェーンを確認します

Appleは、旧Developer ID Certification Authority（G1）の有効期限を2027年2月1日と告知しています。同日以降、影響を受ける証明書で署名したインストーラパッケージはインストールできなくなるため、まず発行元を確かめ、対象PKGはG2のDeveloper ID Installerで再署名して実機で検証します。ただし、安全なタイムスタンプ付きで既に公証されたMacアプリとPKGは同じ扱いではありません。(AppleのG1期限告知)

対象となる証明書は、名前や有効期限だけで決めつけず、証明書チェーンで確認してください。

macOSアプリの公開責任者：既存の署名資産がG1の影響を受けるか確認したい方。
CI/CD基盤エンジニア：署名ID、キーチェーン、成果物の検証手順を見直す方。
企業IT・環境管理者：本番公開を止めずに検証できるMacビルド環境を整えたい方。

最終更新：2026年10月26日。期限と対象範囲はAppleの2026年10月1日付告知および証明書の置き換え手順で確認しています。

証明書名と期限の表示だけでは、G1か判断できません

影響範囲を調べるときは、Apple Developerの証明書一覧でDeveloper ID ApplicationとDeveloper ID Installerをそれぞれ確認します。Appleは、2027年2月1日以前に期限を迎える証明書を影響対象の可能性があるものとしていますが、期限日だけでは発行元を確定できないと説明しています。(Appleの証明書置き換え手順)

Developer ID Installer証明書がどの中間証明書から発行されたか、どう確認しますか？

キーチェーンアクセスで対象の証明書を選び、「発行者名」の「組織単位」を確認します。Appleの案内では「Apple Certification Authority」と表示されるものは旧Sub-CA由来、「G2」と表示されるものは現行Sub-CA由来です。証明書名が同じものを複数保有している場合もあるため、一覧の表示名だけで判定せず、対象の証明書自体を選んでください。

混同しやすいのは、開発用の証明書、アプリ署名用の証明書、PKG署名用の証明書が別々に管理される点です。Appleの証明書作成ガイドでは、Developer ID ApplicationはMacアプリに、Developer ID Installerはインストーラパッケージに使うと説明されています。片方だけを置き換えても、もう片方の署名は自動では切り替わりません。(Developer ID証明書の作成ガイド)

既存の証明書で署名を続ける運用があるなら、旧中間証明書を先にキーチェーンから削除しないでください。Appleは、旧証明書に関連する署名を行う間は、期限を迎える中間証明書も保持するよう案内しています。移行の完了までは、新旧の中間証明書と署名IDを対応づけて管理するのが安全です。(中間証明書の更新に関する案内)

PKG、既存アプリ、今後の更新では影響が異なります

この区別はAppleの期限告知に基づきます。すべての古いPKGやDeveloper ID証明書が影響を受けるわけではなく、また、PKGについての対応をDMGやアプリ本体など、別形式の配布物へ一律に当てはめることもできません。

G1の期限後、すでに公証済みのMacアプリも再署名が必要ですか？

安全なタイムスタンプ付きで既に署名・公証されたMacソフトウェアについて、Appleは動作を継続し、対応不要としています。一方、今後の更新では新しい証明書で署名し、公証用の安全なタイムスタンプを含める必要があります。アプリを収めたPKGは別に判定し、PKGの署名証明書が影響対象かを確認してください。

PKGのインストール失敗は、アプリ内部の署名ではなく、インストーラ自体の署名チェーンが原因のことがあります。失敗した場合はエラー表示、PKGの署名ID、発行元をセットで記録し、アプリとインストーラを別々に調べます。

G2への切り替えで起きやすいのは、証明書の選択違いです

移行では、新しい証明書を作成しただけで完了とせず、発行元と用途を確認します。Appleは証明書の作成時に中間証明書を選ぶ画面が表示された場合、「G2 Sub-CA」を選ぶよう案内しています。別の選択肢では、2027年に期限を迎える証明書が発行される可能性があります。

Appleは、Xcode 11.4以前を使用している場合は新しい証明書の作成前にアップデートするよう告知しています。チーム内に古いビルドノードが残っている場合は、ノードごとのXcodeと署名方式を確認し、実際にG2証明書を使える環境で署名できることを試験してください。

CIで「ビルド成功」と「署名移行完了」を分けて検証します

ビルドが正常終了しても、ジョブが意図した証明書と秘密鍵を使ったとは限りません。複数のキーチェーン、自己署名ID、環境変数による設定上書き、公開鍵証明書だけがインストールされたノードなどがあると、ローカルとCIで別のIDを参照することがあります。署名資格情報をログへ出さず、アクセス権と保管場所を別途管理します。運用ルールの整理には、データ保護に関する案内も参照してください。

移行時は、次の順で代表的なリリース経路を検証します。

1. 既存資産を棚卸しします。 Developer ID ApplicationとDeveloper ID Installerを分け、証明書名、発行元、期限、秘密鍵の所在、利用中のジョブを記録します。
2. 影響対象を特定します。 キーチェーンアクセスで発行者の組織単位を確認し、G1由来の証明書とG2由来の証明書を台帳上で区別します。
3. G2の証明書と秘密鍵を用意します。 Application用とInstaller用の用途を取り違えず、作成画面でG2 Sub-CAを選択したことを確認します。
4. CIの署名設定を切り替えます。 対象ノードに必要な証明書と秘密鍵がそろっているか確認し、署名IDを明示してビルドします。秘密情報はログ、成果物、共有可能な設定ファイルへ出力しません。
5. 成果物の署名チェーンを検証します。 アプリにはcodesign、PKGにはpkgutil --check-signatureを使い、署名者とタイムスタンプを記録します。Appleもアプリとインストーラで確認に使うツールを分けて案内しています。(署名と公証のトラブルシューティング)
6. 配布を想定したインストール試験を行います。 本番とは分離したMac環境で代表的なPKGをインストールし、必要な公証処理、起動、更新まで確認します。CIのログには判定結果と署名IDを残し、秘密鍵や認証情報は含めないようにします。
7. 証跡を保存してから公開へ進みます。 移行前後の署名情報、使用したジョブ、試験対象、インストール結果を記録します。ビルド成功だけでなく、成果物とインストールの両方が通ったことをリリース判定条件にします。

G2へ切り替えた後、CIのPKGインストールをどう確認しますか？

ジョブが使用した署名IDと証明書チェーンを確認したうえで、生成されたPKGをpkgutil --check-signatureで検査し、隔離したMacに実際にインストールします。検証コマンドの成功だけで導入可否を判断せず、対象OS、インストール結果、失敗時の表示を記録してください。Appleが示す署名検査は公式要件の確認に使い、チームのリリース基準は実際のCIと配布先での試験結果として別に残します。

この作業では、既存の署名設定を本番ジョブ上で一度に置き換えるより、隔離した検証ジョブでG2署名からインストールまで通し、差分を確認してから公開経路へ反映する方法が適しています。自社のMacが常時確保され、物理インターフェースや専用ハードウェアを使うなら、既存設備で検証する方が適する場合もあります。反対に、リリースを止めずに別の検証環境を用意したい場合は、企業向けMac CIと環境の確認ガイドを読み、必要な隔離条件を先に整理してください。

G1由来の証明書を使うPKGを残したまま期限を迎えると、配布済みパッケージがインストールできなくなり、再署名・再配布の調整も必要になります。手元のMacだけで検証する運用は、共有中の環境を止める、検証条件が本番と異なる、資産の管理担当が曖昧になるといった制約が出ることがあります。独立したMac環境が必要な場合は、xcodeopsのリモートMac環境を選択肢として確認し、署名チェーンの検証とPKGのインストール試験に必要な条件を事前に照合してください。