codesign errSecInternalComponent：2026年のリモート署名はどう直す？

再試行を繰り返す前に、次の情報を伏せ字で保存します。

• 実際にビルドを実行したmacOSユーザー名
• SSH、LaunchAgent、Runnerなどのログイン経路
• 使用されたKeychainのパス
• codesign、xcodebuild、Archiveのどの段階で停止したか
• 対象Bundle ID、署名方式、Apple DistributionまたはDeveloper IDの別
• 完全なエラー出力から、パスワード、Team ID、証明書ハッシュ、成果物名を置き換えたログ

Appleのコード署名に関する公式フォーラム資料でも、署名処理を単一のエラー文字列だけで判断せず、証明書、秘密鍵、Keychain、プロファイルを分けて調べる方向が示されています。失敗直後にKeychainを全消去したり、証明書を撤回したりすると、比較材料と復旧経路を同時に失います。

まず、署名対象を変更しない最小テストを用意します。例として、テスト用アプリの実際のパスを明示的な占有語に置き換えます。

security find-identity -v -p codesigning
codesign --display --verbose=4 "/PATH/TO/APP.app"
codesign --force --sign "SIGNING_IDENTITY_PLACEHOLDER" "/PATH/TO/APP.app"

同じユーザーでグラフィカルなターミナルとSSHの両方から実行し、署名IDと成果物を一致させます。グラフィカルな側だけ成功するなら、証明書名の誤りよりも、SSHセッションでKeychainが解除されていない、または秘密鍵への許可を表示できない可能性を先に調べます。

両方で失敗する場合は、セッション差ではなく、署名IDの完全性、秘密鍵、証明書チェーン、Provisioning Profileに焦点を移します。Appleのコード署名証明書に含まれる情報の技術説明を参照し、証明書名だけでなく用途と公開鍵の対応を確認します。

security find-identity -v -p codesigningに表示されることは、証明書がコード署名用途として見つかったことを意味します。しかし、それだけで対応する秘密鍵が利用可能とは限りません。証明書だけを移行し、秘密鍵を含むデジタルIDを移していない構成では、一覧に表示されても署名時に失敗します。

Keychain Accessでは対象証明書を展開し、対応する秘密鍵が同じKeychainに紐付いているか確認します。次の点も記録してください。

• 期限切れの証明書と現行証明書が同名で残っていないか
• 証明書と秘密鍵が別のKeychainに分散していないか
• Apple DistributionとDeveloper IDを用途違いで選択していないか
• SSHの実行ユーザーが、証明書を登録したユーザーと一致しているか
• Provisioning ProfileのBundle ID、Team、用途がArchive対象と一致しているか

Appleの証明書タイプの公式一覧では、配布用証明書などの用途が区別されています。iOSアプリのArchiveでApple Distributionを使う場合、macOSアプリの配布で使うDeveloper IDとは、同じ「配布用」に見えても選択条件が異なります。

Provisioning Profile側も、App Store用Provisioning Profileの作成条件と照合します。署名証明書を直してもProfileの対象App IDや entitlements が異なれば、ArchiveやExportの段階で別の失敗になります。

SSHだけで失敗する場合は、ビルドユーザーのコンテキストでKeychainを明示し、ジョブ開始時に解除できる状態を作ります。パスワードはシェル履歴やログに直接書かず、CIの秘密情報ストアから一時的に渡します。

security list-keychains -d user
security default-keychain -d user
security unlock-keychain -p "$KEYCHAIN_PASSWORD" "/PATH/TO/BUILD.keychain-db"
security show-keychain-info "/PATH/TO/BUILD.keychain-db"

KEYCHAIN_PASSWORDやパスは占有語のままにし、実環境の値を記事やリポジトリへ貼り付けないでください。Keychainのアクセス制御を変更する場合は、署名に必要なツールだけへ最小限の許可を与え、広範囲な常時許可や安全機構の無効化を標準手順にしないことが重要です。

sudoで別ユーザーとして署名したり、rootのKeychainを解除したりすると、グラフィカルなArchiveで使っていたデジタルIDと別の環境を調べることになります。修復コマンドは、実際にxcodebuildまたはfastlaneを起動するユーザーで実行してください。

AppleのKeychain技術資料が示すように、Keychainは単なる証明書ファイル置き場ではありません。ロック状態、ユーザーコンテキスト、秘密鍵へのアクセス制御が、SSHのような非対話セッションでの成否に影響します。

codesignの単体テストが成功しても、実際の配布物が完成したとは判断できません。脱​​敏したテストプロジェクトで、次の順に確認します。

• [ ] 同じビルドユーザーでKeychainのパスと解除処理を確認する
• [ ] security find-identity -v -p codesigningの結果を保存する
• [ ] 証明書と対応する秘密鍵が同じデジタルIDとして存在することを確認する
• [ ] xcodebuild archiveを実行し、Archive対象のBundle IDとTeamを記録する
• [ ] 埋め込まれたProvisioning Profileとentitlementsを確認する
• [ ] Export処理でApple Distributionまたは適切なDeveloper IDが選ばれることを確認する
• [ ] 署名済みアプリのネストしたFrameworkやExtensionも検証する
• [ ] App Store Connectへのアップロード直前まで、同じSSHジョブで再現する
• [ ] 失敗時にKeychainパスワードや秘密鍵がログへ出ないことを確認する

Xcodeの設定名や署名関連の評価順序は、公式のBuild Settings Referenceと実際のArchiveログを突き合わせます。証明書チェーンを構築できない、IDが無効、秘密鍵が見つからないといった結果が出た場合だけ、必要な中間証明書の補充、デジタルIDの再インポート、署名資産の輪換を選びます。

Profileを編集、再ダウンロード、削除する場合も、AppleのProfile管理手順を先に確認します。削除は既存のビルドや別のMacにも影響し得るため、現在のProfileを保存し、どのBundle IDと環境へ戻せるかを記録してから実行します。

最後の判定は、画面を開いた状態で一度成功したかではありません。次の状態を順に再現し、実際のArchiveジョブが人の操作なしで完了するか確認します。

• グラフィカルなログイン状態でArchive
• グラフィカルなセッションを終了した状態でSSH接続
• SSHを切断して再接続した後のArchive
• ジョブ失敗後に同じKeychain初期化処理を行う再試行
• Macを再起動した後のKeychain初期化とArchive

各結果には、実行時刻、ユーザー、Keychainパス、署名ID、ArchiveまたはExportの成否、復旧手順を残します。人工的な許可ダイアログが一度でも必要なら、まだ無人運用には合格していません。

現在のMacで画面ログインを維持しなければ署名できない場合、原因を直せないまま発行日に運用を続けるのは危険です。自社のMacレンタル環境を確認し、常時接続できる実機Mac上でビルドユーザーとKeychainの状態を保持できる構成へ移すか、現在の環境を修復するかを、必要な保持期間と物理アクセス要件から判断します。

共有Runnerや一時的なクラウド環境では、ビルドのたびにユーザーコンテキストが変わる、Keychainが初期化される、SSHからGUIの許可ダイアログを処理できない、という欠点が残りやすいです。自前のMacを購入する方法は状態を保持しやすい一方、署名専用機の保守、稼働場所、故障時の復旧を小規模チームが引き受けます。

一方、NUKCLOUDのMacレンタルなら、SSHやVNCで接続できる実機Macを、継続的なiOSビルド環境として検証できます。短期のリリース対応や移行検証では、まずログアウト、再接続、再起動後の実Archiveを合格させ、長期運用で物理ポートや固定されたハードウェアが必要かを確認したうえで、日本向けの利用案内を検討するのが安全です。恒常的な高負荷処理や物理機器への直接接続が必須なら、自社保有のMacが適する場合もあります。

グラフィカルなターミナルでは動くのに、SSH経由のcodesignだけ失敗するのはなぜですか？

同じユーザーであっても、SSHセッションはログインKeychainが自動解除されず、秘密鍵への対話的な許可も表示できない場合があります。まず同じ成果物と署名IDを使って両方のセッションを比較し、SSH側だけ失敗するなら証明書の再発行ではなく、Keychainのロック状態とアクセス制御を確認します。

errSecInternalComponentが出たらApple Distribution証明書を作り直すべきですか？

直ちに作り直す必要はありません。このエラーは汎用的なコード署名エラーであり、SSHのユーザーコンテキスト、Keychainのロック、秘密鍵の欠落、証明書チェーンなど複数の原因で発生します。署名IDに対応する秘密鍵が存在し、グラフィカルなセッションでも失敗する場合に限り、再インポートや資産の輪換を検討します。

署名証明書に対応する秘密鍵があるか確認する方法はありますか？

security find-identityで表示される証明書名だけでは、秘密鍵との組み合わせまで保証されません。Keychain Accessで対象証明書を展開し、対応する秘密鍵が同じKeychainに紐付いていることを確認してください。証明書、秘密鍵、Keychainのユーザーを別々に確認し、同名の古い証明書を有効なIDと取り違えないことが重要です。

リモートMacからログアウトした後も自動署名を維持するには何が必要ですか？

ビルドを実行するユーザーのKeychainを明示的に指定し、ジョブ開始時に安全な方法で解除できるようにします。そのうえで、署名ツールに必要な最小限のアクセス権だけを設定し、ログアウト、SSH再接続、ホスト再起動後にArchiveを再実行してください。人工的な許可ダイアログに依存する構成は、無人運用の合格条件に含めません。

security find-identityに証明書が表示されるのに署名できないのはなぜですか？

表示結果は、証明書がコード署名用として認識されたことを示すだけで、秘密鍵の存在、Keychainの解除、アクセス制御、Provisioning Profileとの一致までは示しません。対象Bundle ID、entitlements、Team ID、署名用途をArchiveの実際の出力と照合し、証明書だけが残っている状態や別Keychainに秘密鍵がある状態を除外してください。