AppleのDTS排障資料は、errSecInternalComponent がSSHやCIなど標準的でない署名環境で発生し得ることを示しています。AppleのCode Signing関連資料も確認できます。したがって、先に証明書を再インポートするのは適切ではありません。図形ログインのTerminal、SSH、Jenkins Jobで同じmacOSアカウント、署名身份、テストファイルを使い、数字身份、Keychainの解錠、ACL、Agentの安全コンテキストの順に証拠を集めます。
本番公開では、非rootの専用署名アカウントと隔離ノードを使います。さらに、ホスト再起動後とAgent再接続後に無人署名が戻ることを確認できなければ、公開ノードとして登録しません。
最終更新：2026年9月5日。Apple DTSの改訂履歴、Keychain関連資料、Security Frameworkのエラー定義、Jenkins公式Agent資料を基に確認しています。
[ SECTION_01 ] 対象読者と最初に固定する診断条件
Jenkins Mac Agentを保守し、iOSまたはmacOSの公開パイプラインを復旧するプラットフォーム担当者向けです。証明書の秘密鍵、Keychain権限、公開監査を管理する企業セキュリティ担当者にも適しています。
遠隔Macが無人署名と障害復旧に耐えられるかを評価するIT購買担当者は、最後の受け入れ基準まで確認してください。
最初に固定するのは、失敗箇所です。図形セッションでは署名できるのに、同じアカウントのJenkins JobだけがerrSecInternalComponentを返すなら、証明書そのものより実行環境の差を優先して調べます。Job内で次の最小テストを実行し、完全なログではなく失敗したコマンド、終了コード、実行者、HOME、使用Keychainを保存します。
security find-identity -v -p codesigning
codesign -s "署名身份名" --force --verbose ./Test.app
テスト用証明書とテスト用アプリを使います。秘密鍵、Keychainパスワード、認証情報をJenkinsfile、通常の環境変数、ビルドログへ出力してはいけません。
[ SECTION_02 ] 5つの指標で見るJenkins errSecInternalComponent
単純な「Terminal→SSH→Jenkins→再起動」という時系列ではなく、同一テストの結果を指標別に比較します。次の表は、診断記録を作るための決定表です。
| 指標 | 確認する状態 | 典型的な判定 | 次の対応 |
|---|---|---|---|
| 数字身份の有効性 | 証明書と対応する秘密鍵、信頼状態 | 証明書だけ見える場合は署名不可 | 完全な身份と証明書チェーンを確認 |
| Keychainの可用性 | 実際のKeychain、解錠状態、検索範囲 | 図形ログインだけ成功なら会話状態を疑う | Jenkins実行時の解錠と検索範囲を固定 |
| ACLと秘密鍵アクセス | codesignが無対話で秘密鍵へ到達できるか |
ポップアップ待ちやACL拒否 | 必要な署名ツールだけに許可 |
| Agentの安全コンテキスト | 所有者、HOME、起動方式、ログイン状態 |
Unixユーザーだけ同じでも失敗し得る | 専用アカウントと起動条件を統一 |
| 隔離と復旧能力 | Job権限、ノード分離、再起動後の復帰 | 人手のクリックが必要なら本番不可 | 専用ノードで無人復旧を再試験 |
数字身份は「証明書が見える」だけでは足りません
証明書がmacOS Keychainに表示されるのに署名できない場合、何を確認するべきでしょうか。
証明書と秘密鍵が同じKeychainに存在し、署名に使える一組の数字身份になっているかを確認します。証明書の表示だけでは秘密鍵の存在や対応関係を証明できません。AppleのCode Signing Certificatesの内部構造に関する技術ノートを基準に、security find-identityの結果、証明書の期限、信頼状態、中間証明書チェーンを記録します。
期限切れ、秘密鍵の欠落、信頼されないチェーン、別の秘密鍵との組み合わせは、同じエラー文字列でも原因が異なります。重複インポートを続けると、Jobが選ぶ身份が不明確になり、監査も難しくなります。
Keychainの解錠とACLを別々に判定します
SSHでログインした後にエラーを解消するには、Keychainを開けば十分でしょうか。
十分とは限りません。図形ログインでは自動的に解錠されるKeychainが、SSHやAgentの非対話セッションではロックされたままになることがあります。Jenkinsが実際に参照するKeychainの名前、解錠状態、検索リストを、Jobの実行者で確認します。
次の観察を分けて記録してください。
- Keychain自体がロックされているか。
- 署名身份が検索範囲に含まれているか。
- 秘密鍵のACLが、必要な署名ツールからのアクセスを許可しているか。
- アクセス時にGUIの確認画面を要求していないか。
ACLやpartition listを変更する場合も、許可対象は必要な署名ツールに限定します。無制限の許可やroot実行で回避すると、秘密鍵の露出範囲が広がります。AppleのCode Signing技術ノートの別バージョンも照合し、対象OSの挙動と手順を隔離アカウントで検証します。
Agentの実行コンテキストを固定します
Jenkinsはコンパイルできるのに、codesignだけ失敗するのはなぜでしょうか。
コンパイルは秘密鍵へのアクセスを必要としないためです。codesignの段階では、証明書、秘密鍵、Keychainの解錠状態、ACL、実行プロセスの安全コンテキストが同時に成立する必要があります。
Jenkins公式のノード管理資料とAgentの実行資料に沿って、次を比較します。
- Agentプロセスの所有者。
- Job内の
HOMEと図形TerminalのHOME。 - Agentの起動方式。
- ログイン済みセッションの有無。
- Jenkins Controller側の資格情報と、macOSローカルの署名身份の区別。
「Unixユーザーを切り替えれば同じ環境になる」とは判断しません。sudoやrootを一般的な修復手段にするのも不適切です。Jobの実行者と対話テストの実行者が一致しない場合、まずその差を証拠として扱います。
長尾診断を最小テストへ落とし込みます
私鍵、ACL、ユーザーコンテキストのどこが原因かをどう判定しますか。
図形Terminalでは成功し、SSHでも同じアカウントと同じテストファイルで成功するなら、Agentの起動方式やJenkinsの環境変数が候補になります。SSHだけ失敗するなら、Keychainの解錠、検索範囲、非対話アクセスを優先します。三つすべてで失敗するなら、数字身份、秘密鍵、証明書チェーンを先に疑います。
ただし、これは症状から作る切り分け表です。コミュニティ事例を一般則にせず、各結果をsecurity find-identity、codesignの出力、実行者、Keychain状態で裏付けます。
[ SECTION_03 ] 署名を隔離し、資格情報の露出を限定する
通常のPRビルド、アーカイブ作成、正式公開署名を同じノードと同じ権限に集約してはいけません。PR用Jobは秘密鍵を持たないノードへ、正式公開は専用署名ノードへ分けます。
構成を決める際は、次の境界を明文化します。
- ノードラベルで公開署名Jobだけを専用ノードへ割り当てる。
- JenkinsのJob権限で、誰が正式署名を起動できるかを制限する。
- ログに秘密鍵、Keychainパスワード、認証情報を残さない。
- 作業領域、証明書材料、テンポラリーファイルの削除結果を記録する。
- 署名ノードのアクセス、Job実行者、承認者、失敗理由を監査可能にする。
ログインKeychainは既存環境との互換性を確認しやすい一方、他の用途との境界が曖昧になりやすい構成です。専用の一時KeychainはJob単位の分離に向きますが、生成、解錠、破棄を自動化できることが条件です。専用公開ノードは隔離性が高い一方、容量、保守、復旧手順を別に設計する必要があります。
企業で実機のMacを購入する場合は、Mac miniの導入候補をハードウェア調達の比較材料にできます。ただし、機種選定だけではKeychainの無人復旧や署名監査までは解決しません。
[ SECTION_04 ] 再起動後の無人復旧を本番条件にする
Jenkins Agentの再起動後にコード署名を自動復旧するには、何を合格条件にしますか。
主な条件は、ホスト再起動、Agent再接続、図形ログインなしの状態で、最小署名と実際のアーカイブ作成が再び成功することです。人がKeychainの確認画面をクリックして初めて成功するなら、無人公開ノードとしては不合格です。
実施手順は次の通りです。
- 非本番証明書とテスト用アプリで、三つの実行経路の基準ログを保存します。
- 証明書、秘密鍵、数字身份、Keychain名、検索範囲を棚卸しします。
- 専用非rootアカウントでAgentを起動し、
HOMEと所有者を固定します。 - 必要な署名ツールだけにACLを付与し、無対話の
codesignを確認します。 - PR、アーカイブ、正式公開のJobをノードと権限で分離します。
- ホストを再起動し、図形ログインなしでAgent接続、Keychain復旧、最小署名を確認します。
- 実際のアーカイブを実行し、失敗ログ、修復操作、再起動後の結果、資格情報の消去記録を一つの受け入れ資料にまとめます。
この手順で、SSH後だけ失敗するのか、Agent再接続後だけ失敗するのかを再現できます。AppleがKeychainの挙動を更新した場合、またはJenkinsのAgent起動方式を変更した場合は、隔離テストをやり直します。
[ SECTION_05 ] 現行設備と遠隔Macを選ぶ判断
既存の社内Macを使い続ける場合、物理アクセス、固定ネットワーク、既存証明書との互換性は利点です。一方で、再起動時の有人対応、単一障害点、公開鍵を持つノードへのアクセス範囲、容量増設の遅さが負担になります。
短期の署名検証や、既存設備を変更せずに隔離試験を行う場合は、NOVAKVMのMacレンタル案内を独立した検証ノードとして比較できます。図形アクセス、SSH、専用アカウント、Agent再接続、再起動後の署名という同じ証拠表で評価すれば、単に「Macへ接続できる」ことと「無人公開ノードとして合格する」ことを区別できます。なお、長期にわたり高負荷の公開処理を固定運用する場合や、物理ポート・社内機器への直接接続が必須の場合は、自社保有のMacのほうが適しています。
最終的な判定は、証明書を再インポートできたかではありません。非rootの専用署名アカウントで、隔離されたMacが、再起動後も人のクリックなしに署名でき、資格情報と監査記録を残せるかです。既存設備でその検証期間を確保できない場合は、NOVAKVMの遠隔Macを短期の独立検証ノードとして同じ受け入れ試験にかける方法が現実的です。