症狀：Mac CI 使用的 Developer ID 憑證可能由即將到期的原 Sub-CA 簽發，不能只看憑證名稱或有效日期。 最快解法：先查 Issuer；確認受影響後，換用 Developer ID Certification Authority (G2) 簽發的憑證，並在隔離的 Mac CI 工作中驗收簽名與公證。
本文適合維護 macOS App 簽名、公證與分發流程的工程師，以及管理 Mac CI 節點和鑰匙圈的 DevOps 工程師。
如果你負責發布，請另外確認 .pkg 與已公證 Mac App 的處理方式不同，並保留可回退的發布路徑。
最後更新於 2026 年 11 月 7 日；日期與處理範圍核對自 Apple 到期公告、Developer ID 憑證替換指南及 Developer ID 中間憑證說明。
先按產物判斷 Developer ID G2 憑證過期的影響
Apple 已公告，原 Developer ID Certification Authority (Sub-CA) 將於 2027 年 2 月 1 日到期；受影響憑證及交付物應按官方公告分開處理，而非把所有 Mac App 一概列為必須重簽。公告列出的到期日與適用範圍是排程依據，但你仍須先確認實際憑證的 Issuer。
| 交付物／用途 | 到期影響判斷 | 建議驗收與處置 | 評分：優先度 |
|---|---|---|---|
| Developer ID Application 簽署的 Mac App | 已公證且帶有安全時間戳的既有 App，Apple 說明不會只因這次到期就必須重簽 | 核對簽名、時間戳與公證狀態；勿把例外擴大解讀為所有 App 都不受影響 | 高 |
Developer ID Installer 簽署的 .pkg | 若由受影響的舊憑證簽署，須在到期日前完成替換簽名 | 用 G2 Installer 憑證重簽，並驗證實際交付的套件簽名 | 最高 |
| 尚未分類的產物 | 僅憑憑證到期日或憑證名稱不能判定 | 查明簽署憑證、Issuer、用途與公證紀錄後再決定 | 高 |
在替換前盤點流水線實際使用的憑證
先從開發者帳戶的 Certificates、Identifiers & Profiles，以及建置設定、簽署腳本和 CI 憑據中，列出每個環境實際呼叫的憑證。不要只盤點帳戶裡目前有效的憑證：流水線可能仍引用舊的憑證名稱、匯出的憑證檔，或另一個使用者的鑰匙圈。
如何確認 Mac CI 使用的憑證由哪個 Sub-CA 簽發？先定位 CI 任務實際選中的簽署身分，再檢視該憑證的 Issuer；憑證用途和有效期只能協助篩查，不能取代 Issuer 核對。可在實際執行帳戶下列出可用的簽署身分：
security find-identity -v -p codesigning接著從鑰匙圈匯出對應憑證，檢視 Issuer、Subject 與有效期；若用 codesign -dv --verbose=4 檢查既有 App，則把簽名資訊與帳戶中憑證的 Issuer 一併對照。Apple 的程式碼簽名檢查指引可作為檢查依據。
盤點表至少記錄以下項目，並把憑證用途分成 Application 與 Installer：
- 憑證名稱、Issuer、有效期及用途。
- 使用該憑證的工作流程、建置設定和簽署指令。
- 憑證與私鑰所在的鑰匙圈、匯入方式，以及 CI 執行帳戶。
.pkg、App、安裝程式或其他交付物分別使用哪個簽署身分。
注意：同一台 Mac 上能看到新憑證，不代表 CI 任務能讀取其私鑰。請在正式任務使用的帳戶與非互動執行環境中驗證，而不是只用管理員帳戶手動簽一次。
依用途建立 G2 憑證並安排安全交接
建立替換憑證時，依官方流程選擇 Developer ID 憑證及 G2 Sub-CA，並逐一核對用途。Apple 的建立指南與替換指南提供目前的帳戶操作步驟；介面選項或舊版 Xcode 的限制如有變動，應以這些現行說明為準，不要沿用未核實的舊教學。
| 憑證類型 | 用途 | 替換時不可混用的項目 | 驗收評分 |
|---|---|---|---|
| Developer ID Application | 簽署要在 Mac 上分發的 App | 確認簽名身分可由 App 建置與公證流程使用 | 高 |
| Developer ID Installer | 簽署 .pkg 安裝包 | 確認套件簽名工作呼叫的是 Installer 憑證，而非 Application 憑證 | 最高 |
.pkg 的簽名工作已完成。
匯出或部署憑證時，先指定交接責任人，再確認憑證、私鑰、鑰匙圈匯入方式和 CI 憑據如何更新。私鑰不應隨建置產物或一般日誌流轉；更新後也不要立即移除舊簽署路徑，應先保留能回到已知可用版本的設定。
在隔離 Mac CI 任務中試跑簽名與公證
建立不發布正式版本的隔離任務，讓它使用與生產工作相同的 macOS 執行帳戶、建置設定、鑰匙圈和簽署參數。這一步的目標不是證明開發者電腦上能簽名，而是確認 CI 能取得正確憑證與私鑰，並依序完成簽名、公證提交及結果查驗。
Developer ID G2 替換後，Mac CI 要重新驗收哪些步驟？至少把憑證可見性、App 簽名、公證提交、公證結果查閱和最終交付物檢查分開記錄。Apple 的命令列公證工作流程涵蓋提交與結果處理；一次手動簽名成功，不能取代完整的 CI 驗收。
可按以下順序執行，並把每一步的工作識別碼、日誌和產物雜湊存入發布證據：
- 以正式 CI 執行帳戶啟動隔離工作，確認工作能列出並使用預期的 G2 憑證。
- 建置測試 App，檢查簽名身分、簽名完整性與預期的 entitlements；記錄實際使用的憑證。
- 使用正式公證流程提交測試產物，保存提交回應與工作日誌。
- 另行查閱公證結果，確認狀態符合發布政策；若使用 stapling，對完成後的產物再執行驗證。
- 對簽名或公證失敗情況確認錯誤會阻止發布，並驗證工作沒有靜默改用另一張憑證。
- 檢查產物、簽名與公證證據互相對應，再將隔離工作結果交由發布負責人核准。
依產物分別驗收重簽結果
對 .pkg，在隔離任務中使用 G2 Developer ID Installer 憑證完成簽名，再以 pkgutil --check-signature 檢查實際安裝包的簽名資訊。確認簽名顯示預期身分與憑證鏈後，將受影響的舊簽安裝包列入替換清單，並安排在 2027 年 2 月 1 日前完成重簽與交付替換；到期日與官方範圍以Apple 公告為準。
對 Mac App，使用 codesign 檢查簽名，並分別確認公證結果與安全時間戳。若 App 已符合 Apple 公告所述的公證及時間戳條件，不要因為 .pkg 需要重簽，就推論 App 也必須重簽；反過來，也不要把 App 的條件直接套用到安裝包。
推廣至正式節點並建立到期複核
隔離驗收通過後，逐台更新正式 Mac CI 節點的憑證引用和鑰匙圈設定；每次變更都保留舊版設定、回退指令、驗收日誌及產物紀錄。完成推廣後，從開發者帳戶重新核對憑證類型、Issuer 和有效期，並按 Developer ID 憑證替換指南建立後續續期提醒。
最終放行可採下表判定；任一關鍵證據缺失時，先停止受影響產物的發布，而不是以「建置成功」代替簽名驗收。
| 驗收門檻 | 通過條件 | 評分：放行判斷 |
|---|---|---|
| Issuer 與用途 | CI 實際使用的憑證已確認為正確 G2 類型，Application／Installer 用途相符 | 高 |
| 執行帳戶 | 隔離任務以正式 CI 帳戶完成簽名，且沒有改用錯誤身分 | 高 |
| 公證證據 | 提交與結果查驗分別留存，狀態符合發布要求 | 高 |
| 交付物 | .pkg 已用正確 Installer 憑證重簽；App 的時間戳與公證狀態已核對 | 最高 |
| 回退與複核 | 正式節點可回退，憑證 Issuer 與有效期已安排定期檢查 | 中 |