Developer ID G2 憑證怎麼遷移？2026 Mac 簽署驗收

Apple 於 2026 年 10 月 1 日公告，舊 Developer ID Certification Authority 將於 2027 年 2 月 1 日到期；Apple 到期公告指出的期限，代表應先核對憑證簽發機構，再分別處理 Mac 應用程式與 .pkg，不能把兩種交付物一概要求重簽。

症狀：簽署流程仍沿用舊 Developer ID 身分，卻不確定哪些發行檔會受影響。
最快解法：先確認簽發者；受舊機構影響的憑證應換成 G2，並在期限前重簽受影響的安裝包。帶安全時間戳且已公證的既有 Mac 應用程式，依 Apple 公告不必只因 Sub-CA 到期而全部重簽。

Mac 獨立開發者：透過 Developer ID 對 Mac App Store 以外渠道發行軟體，需要判斷應用程式簽署憑證是否受影響。
Mac 軟體發行團隊：交付 .pkg 安裝包，需要安排 G2 憑證替換、重簽與安裝驗收。
CI/CD 工程師：在 macOS 建置流程使用 Developer ID 憑證，需要更新鑰匙圈與簽署任務，並驗證發行鏈路。

最後更新於 2026 年 10 月 28 日；截止日期與影響範圍核實自 Apple 的到期公告、Developer ID 憑證替換指南及憑證說明。

先按交付物界定遷移範圍

這次變更的決策核心不是「所有 Developer ID 憑證是否都要立即更換」，而是目前使用的憑證是否由舊的 Developer ID Certification Authority 簽發，以及交付物是應用程式還是安裝包。

Apple 對受影響的 .pkg 有明確的期限要求：應在 2027 年 2 月 1 日前改用替代憑證重新簽署。至於已帶安全時間戳並完成公證的既有 Mac 軟體，Apple 表示可繼續運作；這並不等同於新版本可以繼續使用舊憑證，也不代表所有應用程式都已符合你的發行與支援要求。期限及差異應以Apple 的到期公告和Developer ID 憑證替換說明為準。

交付物或情況	遷移判斷	發行前驗收	風險評級
已帶安全時間戳並已公證的既有 Mac 應用程式	不應僅因舊 Sub-CA 到期就一律重簽；仍須確認實際憑證與發布方式	在目標 macOS 環境檢查簽署資訊及公證狀態	中：依具體簽署與公證狀態判斷
受舊機構簽發憑證簽署的 `.pkg`	在 2027 年 2 月 1 日前更換憑證並重簽	驗證套件簽署資訊，再以新產物測試安裝	高：有明確期限
新版應用程式或安裝包	使用替代的 G2 憑證完成簽署；按發布流程處理公證	分別驗收應用程式或安裝包，不以另一種產物的結果代替	中：須確認流水線沒有引用舊身分

Developer ID Application 用於簽署應用程式；Developer ID Installer 則用於簽署安裝套件。兩者的憑證用途不同，不能只看到團隊名稱相同，就認定已完成兩種產物的遷移。Apple 對 Developer ID 憑證類型的說明列出這些憑證的用途；在盤點時，請把應用程式簽署與 .pkg 簽署分開記錄。

獨立開發者：確認簽發者，不只看憑證名稱

怎麼判斷 Developer ID 憑證是否由舊 Sub-CA 簽發？

請在 Apple Developer 帳戶的憑證清單，以及簽署用 Mac 的「鑰匙圈存取」中檢查憑證詳細資訊，確認憑證類型、簽發者與有效狀態。重點是查看完整憑證資訊中的簽發機構，而非只看憑證名稱、帳戶團隊名稱或到期日；這些欄位本身不足以證明憑證鏈屬於哪個中間機構。

Apple 提供替換 Developer ID 憑證的操作說明，應依其列出的憑證資訊和流程核對。如果帳戶清單和建置機上的結果不一致，先暫停正式發行，確認建置機實際載入的憑證與對應私鑰，避免只在帳戶端建立新憑證、流水線卻繼續使用舊身分。

Developer ID G2 與舊憑證如何區分？

不要只憑「G2」字樣或顯示名稱作判斷。應核對憑證詳細資料中的簽發者，並確認簽署作業使用的憑證及私鑰與帳戶內替代憑證相符。Apple 的Developer ID 中間憑證說明可作為辨識憑證鏈的官方依據；若無法確認簽發者，先不要把該憑證標記為已遷移。

獨立開發者可將已辨識的憑證清單、憑證用途及實際發行檔案一併記錄。這樣在更新版本或重建安裝包時，才能追溯哪個產物由哪個身分簽署，而不是在期限前只憑一份過期提醒作判斷。

發行團隊：讓應用程式與安裝包各自通過驗收

換證後，應用程式與安裝包都要重新簽署嗎？

不一定。若既有 Mac 應用程式已帶安全時間戳且已公證，Apple 公告指出它可繼續運作；但受影響憑證簽署的 .pkg 必須在期限前換證重簽。新版本則應按新的簽署身分重新建立並驗收，不能把既有應用程式的例外解讀成 .pkg 也可不處理。

發行團隊應先盤點實際提供給使用者的檔案：應用程式本體、獨立安裝程式，或兩者都有。接著按產物類型分流：

Mac 應用程式：確認簽署者、時間戳及公證狀態。需要發行新版本時，使用替代憑證簽署，並依原有發布政策處理公證。
.pkg 安裝包：確認套件使用的 Developer ID Installer 憑證；若由受影響的舊機構簽發，換用替代憑證重新簽署，並用新套件做安裝測試。
混合交付：應用程式和 .pkg 各自留下驗收結果，不以其中一種產物的成功簽署推定另一種也已合格。

Apple 的macOS 軟體公證指南說明公證在發行前流程中的位置；如簽署或公證檢查失敗，則依Apple 的常見公證問題排查文件確認錯誤，不要用「成功上傳」取代本機簽署和安裝驗收。

2027 年 2 月 1 日後，舊憑證簽署的 `.pkg` 還能安裝嗎？

不能把期限之後的舊 .pkg 當成已獲 Apple 保證可用的交付物。Apple 公告要求受影響的安裝包在該日期前以替代憑證重簽；因此，採購與發布決策應以完成換證、重簽及新套件驗收為準，而不是把「目前能安裝」當作期限後仍會正常工作的證明。

安裝驗收至少要使用正式發行時會交付的 .pkg，在目標使用環境確認簽署資訊與安裝結果；若產品還包含應用程式本體，也應獨立驗收該應用程式。若公司有不同的安裝方式或更新渠道，將各渠道產物列入同一份清單，避免只測試開發者手上的副本。

注意：憑證到期與憑證鏈切換不是同一個判斷。即使某張憑證顯示仍在有效期內，也要查明它的簽發機構及實際用途；Apple 公告中的例外亦有特定條件，不應延伸成所有舊簽署產物都無需處理。

CI/CD 工程師：先隔離試簽，再更換正式身分

macOS CI 簽名遷移最常漏掉的不是憑證申請，而是流水線仍引用舊的憑證名稱、舊鑰匙圈，或與憑證不相符的私鑰。若建置工作分散在多台 Mac，需逐台核對實際簽署環境；只更新一台建置機，不能證明所有發布任務都已切換。

建議依下列順序執行：

盤點引用：列出各建置任務使用的憑證身分、鑰匙圈參照、簽署設定和輸出產物，分清 Developer ID Application 與 Developer ID Installer。
核對金鑰配對：確認替代憑證及對應私鑰已匯入預定的建置環境，且流水線能使用正確的鑰匙圈；不要將私鑰內容直接寫進程式碼庫或工作記錄。
建立隔離發行任務：先在不影響正式發布的工作中，以新身分簽署代表性的應用程式或 .pkg，並保存可供團隊覆核的簽署與驗收結果。
驗收產物：按交付物類型檢查簽署資訊，對應用程式確認公證狀態，對 .pkg 執行安裝測試；若工作流程包含公證，依 Apple 的自訂公證工作流程文件及官方公證指南處理。
切換並保留回退條件：隔離任務通過後，才更新正式流水線的簽署身分；若新憑證、私鑰或安裝驗收失敗，回退到不發行該產物的安全狀態，而不是退回使用受影響憑證繼續發布。

Apple 的程式碼簽署憑證技術說明可協助理解憑證及時間戳資訊。具體憑證安裝方式、簽署設定和憑據管理方式，仍須按 Apple 文件及團隊既有的安全政策核對；不能假設每種 CI 工具對鑰匙圈的處理方式相同。

團隊負責人：以責任、證據與風險評級安排切換

遷移負責人應將憑證盤點、替代憑證簽發、試簽、使用者側安裝驗收與正式切換分派給明確角色。若直到 2027 年 2 月 1 日才開始處理，留給修正憑證存取或安裝問題的時間會受限；應現在確認交付物及簽發者，再按實際風險安排發布批次。

以下清單可用來決定是否進入正式切換：

[ ] 已從憑證詳細資訊確認簽發機構，而非只依顯示名稱或到期日推斷。
[ ] 已分開列出 Developer ID Application 與 Developer ID Installer，並盤點所有交付中的應用程式及 .pkg。
[ ] 已確認受影響 .pkg 的替代憑證、重簽負責人及期限前的驗收安排。
[ ] 已在隔離任務使用新憑證試簽，並留下可供覆核的產物與結果。
[ ] 已在目標使用環境驗收新應用程式或 .pkg；公證狀態依適用流程確認。
[ ] 已更新正式 CI/CD 的憑證、私鑰與鑰匙圈參照，且設定了驗收失敗時停止發行的條件。
[ ] 已將 G2 憑證本身的有效期納入後續續期管理，不把 Sub-CA 遷移視為免除憑證續期。

團隊角色	必須交付的證據	評級與切換判斷
獨立開發者	憑證簽發者核對紀錄、應用程式簽署與公證狀態	只有確認憑證和產物條件後，才判定既有應用程式是否無需重簽
Mac 軟體發行團隊	`.pkg` 新簽署資訊、安裝驗收結果及發行檔案清單	受影響安裝包尚未重簽或安裝測試未通過，評為高風險，不應正式發布
CI/CD 工程師	隔離試簽紀錄、流水線身分設定、正式任務驗收結果	若仍有任務引用舊身分，評為高風險；全部驗收通過後再切換
團隊負責人	責任分派、期限安排、失敗停止或回退條件	未定義誰核准產物與誰執行回退，不視為完成遷移

如果團隊缺少可用於簽署與驗收的 macOS 環境，現有 Linux 建置機無法代替需要 macOS 工具鏈的簽署檢查；自行購置 Mac 適合長期、固定且持續使用的團隊，但仍需自行維護設備、憑證和建置環境。若目前只需完成一輪憑證遷移、試簽或短期發行驗收，租用 ArmMacs 可避免為一次性工作先購置硬體；若工作長期高負載、需要實體介面，或必須自行掌控設備，則應評估自購方案。可先查看ArmMacs 的 Mac 方案，並參考Mac 支援資訊確認遠端環境是否符合簽署及驗收需求；切換前仍應以 Apple 官方文件核實憑證與交付物狀態。