Developer ID証明書が2027年に期限切れ、どうする？2026年移行チェックリスト

最初にDeveloper ID証明書の署名チェーンを確認し、旧中間証明書の影響があるかを判定してください。該当する場合、.pkgは期限までに新しい証明書で署名し直し、署名済み・公証済みで安全なタイムスタンプを持つMac Appは、期限だけを理由に再署名せず、次回更新から新しい証明書を使います。Appleの告知に基づく判断です。

macOSアプリを配布する個人開発者：Developer ID Application証明書の影響と次回更新の署名を確認します。
.pkgを配布する開発者：旧署名のインストーラーを洗い出し、期限前の再署名と受け入れ確認を計画します。
リモートMacで公開する小規模チーム：証明書、秘密鍵、ビルド環境が同じ署名IDを使うか点検します。

最終更新：2026年10月2日。Appleが公開した期限に関する告知、中間証明書の説明、証明書作成ガイドを照合しています。

Developer ID証明書の2027年期限切れは、署名チェーンで見分ける

対象になるかどうかは、証明書の種類だけで決められません。開発者アカウントの証明書記録で有効期限と発行元を確認し、旧Developer ID Sub-CAによる署名かを照合します。Appleは旧Sub-CAが2027年2月1日に期限を迎え、その発行証明書が同日から機能しなくなると告知しています。個別の証明書記録を根拠に判断してください。

Developer ID Applicationはアプリ本体の署名に使い、Developer ID Installerは署名付き.pkgの作成に使います。名称が似ていても対象の成果物と受け入れ確認は別です。証明書と、その署名IDに対応する秘密鍵も別の資産として点検します。Developer ID証明書の作成時には、中間証明書の選択肢も確認します。

旧Sub-CAの証明書は、どのMac Appに影響するのか

Mac Appへの影響を判断するときは、配布中のアプリが旧証明書で署名されているかに加え、公証済みか、安全なタイムスタンプがあるかを調べます。Appleの説明では、署名済みで公証され、安全なタイムスタンプを含む既存のMacソフトウェアは、今回の期限後も動作を継続します。一方、今後の更新には新しい証明書を使う必要があります。旧中間証明書の影響に関するAppleの説明を基準にし、「旧証明書を使ったアプリはすべて直ちに再署名」とは判断しないでください。

証明書を作り直しただけで、配布済みアプリの署名や公証が自動的に更新されるわけではありません。実際に配布した.appを調べ、署名ID、タイムスタンプ、公証記録をそれぞれ確認します。公証に問題がある場合は、期限対応と混同せず、署名と公証の状態を分けて切り分けてください。

Mac Appと.pkgでは、期限後の影響が異なります

判断軸は「同じ証明書を使っているか」だけではありません。成果物の種類と、既存バージョンを今後どう配布するかを分けて考えます。Appleは、旧Sub-CAの証明書で署名された.pkgについて、2027年2月1日以降はインストールできなくなると説明しています。Appleの期限告知を踏まえ、該当するインストーラーは期限前の再署名と実機での導入確認を計画してください。

表はAppleの期限告知と中間証明書の説明に沿った判断の整理です。特定のユーザー環境での挙動を推測で補わず、再署名後のインストーラーを、実際に配布する経路と導入先で受け入れ確認してください。

Developer ID Installerの.pkgは、いつ再署名するか

旧中間証明書の影響を受けるDeveloper ID Installerで署名された.pkgは、2027年2月1日の期限前に新しい証明書で再署名する方針が安全です。該当する.pkgは期限後にインストールできなくなるため、過去のリリースに.pkgが複数ある場合は、公開場所だけでなく、更新ツールや社内配布に残るファイルも棚卸しします。

再署名後は、署名の検証だけで完了にしないでください。インストーラーが対象のmacOS環境で起動すること、導入するファイルや配置先が想定どおりであること、現在の配布経路で利用者に渡せることを確認します。個別の証明書記録を照合し、実物で受け入れ判定を残します。

注意：再署名の対象は、開発者アカウントに表示される証明書だけで決めず、実際に公開した.pkgの署名情報で照合します。配布済みの旧パッケージを残す場合は、利用者への提供方法もあわせて見直してください。

公開前の受け入れ指標で、証明書移行を判定する

署名とタイムスタンプは、配布物そのもので調べる

.appの署名情報はcodesignで、.pkgの署名はpkgutilで確認できます。以下のコマンドは調査の入口です。表示された署名者が意図した新しいDeveloper IDか、アプリではタイムスタンプを含む情報があるか、実際の配布成果物で確認します。

codesign -dv --verbose=4 "/path/to/App.app" 2>&1
pkgutil --check-signature "/path/to/Installer.pkg"

出力ではAuthorityなどの署名者情報を記録し、アプリの署名詳細にTimestampが示されるかも見ます。.pkgの出力では署名が有効かと署名者を確認します。証明書チェーンや署名の扱いが不明な場合は、Appleのコード署名証明書に関する技術資料と照らし合わせてください。

証明書だけでなく、秘密鍵とビルド環境も一致させる

キーチェーンに証明書が見えていても、署名に必要な対応する秘密鍵がなければ、その環境で同じ署名IDを使えるとは限りません。ローカルMacとリモートMacの両方で、実際にビルドを実行するアカウントから有効な署名IDを確認します。

security find-identity -v -p codesigning

想定したDeveloper ID ApplicationまたはDeveloper ID Installerが表示されるかを確かめます。秘密鍵そのものや、再利用可能な認証情報はログ、画面共有、記事の添付資料に含めないでください。証拠として残すのは、秘密情報を除いた署名IDの確認結果、成果物の署名検査、公開作業の記録です。

旧中間証明書と新中間証明書の選択を混同しない

新しいDeveloper ID証明書を作るときは、発行元が現在のDeveloper ID Certification Authority（G2）であることをアカウント記録と照合します。作成時の中間証明書の選択肢は、利用中の証明書作成画面とAppleの現行ガイドで確認してください。

古いXcodeを含む環境での互換性は、すべてのプロジェクトに共通する一つの設定として扱えません。Appleの作成手順と中間証明書の説明を確認し、対象のビルド環境で署名した実際の配布物を検証します。証明書を作れたことだけをもって移行完了としないのが重要です。

Mac Appの再署名と再公証は、別々に判定する

証明書の更新と公証のやり直しは同じ作業ではありません。既存の公証済みMac Appに安全なタイムスタンプがある場合、今回の期限だけを理由に再署名する必要はないとAppleは説明しています。ただし、新しいアプリ更新を配布する際は、新証明書で署名し、そのリリースの公証状態を実際に確認してください。Developer ID署名のガイドも参照し、旧アプリの継続利用と今後の更新作業を分けて記録します。

秘密鍵を別のMacへ移す場合は、鍵を含む署名資産を保護した方法で移行し、受け取り側で署名IDの利用可否を確認します。秘密鍵のエクスポートや受け渡し方法は、組織のアクセス制御と保管ルールに合わせてください。

受け入れ結果から、保管・移行・再署名を決める

作業を時系列で進めるより、公開判断に必要な指標を揃えると見落としを減らせます。次の順で証拠を残します。

1. 開発者アカウントの証明書記録から、有効期限と発行元を確認します。旧Sub-CAに該当するかが不明なら、影響なしと決めつけず確認を保留します。
2. 配布済みの.appと.pkgを一覧にし、それぞれの署名者、アプリの公証状況、タイムスタンプを調べます。
3. 新しい証明書の発行元と中間証明書の選択を公式資料で確認し、作業対象のMacに対応する秘密鍵があるか検証します。
4. リモートMacを含む各ビルド環境で署名IDを確認し、実際にビルドと署名を実行します。公開作業が複数環境に分かれる場合は、それぞれの環境の結果を記録します。
5. Mac App更新と.pkgを別々に検査し、署名、公証、タイムスタンプ、インストールの確認結果を残します。証明書の作成完了だけで公開可と判定しません。
6. 証拠に基づき、旧証明書の保管、新証明書への移行、影響を受ける過去の.pkgの再署名のいずれを実施するか決めます。

結果は「署名IDが新証明書と一致」「秘密鍵を使える」「公開対象の.pkgを導入できる」「アプリ更新の公証を確認済み」のように項目別に記録します。失敗があれば、証明書発行元、秘密鍵の有無、成果物の署名、公証結果を分けて調べます。これにより、単に証明書を追加しただけの状態と、公開可能な状態を区別できます。

署名移行のためだけに専用Macを購入すると、利用頻度が低い期間もハードウェアを保有し、保守や更新の手間も引き受けます。既存のMacだけで運用する場合は、鍵の移行や環境の共用が制約になることがあります。公開作業用のmacOS環境を独立させたいものの、購入後の維持までは望まない場合は、SFTPMACのMac miniレンタル料金と東京向けMac miniの案内を比較し、証明書・秘密鍵の管理方法や必要な接続方式が公開フローに合うか確認してください。常時高負荷で使う場合や物理ポートが必要な場合は、購入や手元のMacの継続利用も含めて選ぶのが適切です。