先核對簽名證書鏈是否屬於 Developer ID G1，再依產物類型處理：受影響證書簽署的 PKG，應在 2027 年 2 月 1 日前以正確的 G2 身份重簽並驗證；帶安全時間戳的既有公證應用，不應直接套用 PKG 的失效規則。這個判斷適用於負責 macOS 軟體發布、企業簽名資產與 CI/CD 建置環境的團隊。(Apple Developer 公告)
macOS 應用發布負責人：確認現有 Developer ID 簽名資產是否受 G1 中間證書到期影響。
CI/CD 平台工程師：調整簽名身份、鑰匙圈和產物驗收流程。
企業 IT 環境管理員：安排可隔離驗證的 Mac 建置環境，避免直接在生產發布流程試錯。
Developer ID G1 到期與單張證書到期：先確認簽發鏈
Developer ID G1 指原 Developer ID Certification Authority（Sub-CA），不是所有 Developer ID 證書共同的到期日。Apple 已公告，原 Sub-CA 將於 2027 年 2 月 1 日到期；這不等於所有 Developer ID 憑證或所有既有應用程式在同一天失效。
先找到實際用來簽名的 Developer ID Application 或 Developer ID Installer 證書，再查看發行者資訊。Apple 的辨識指引指出，證書的 Issuer Name 中，Organizational Unit 若顯示「Apple Certification Authority」，代表由先前的 Sub-CA 簽發；若顯示「G2」，則屬於目前的 Sub-CA。到期日可用來篩查，簽發者才是確認依據。(Apple 替換 Developer ID 證書指引)
辨識時要選團隊自己的簽名證書，不要把鑰匙圈中同名的 Developer ID Certification Authority 中間憑證，誤當成正在用來簽名的葉憑證。Apple 也提醒，同一團隊可能有名稱相同、但簽發鏈不同的證書；只用證書名稱或日期比對，容易誤判。
這個區分會影響發布安排：如果簽名證書的簽發鏈確認屬於 G1，就進一步盤點由它簽署的產物；如果確認是 G2，則不能只因舊產物或其他證書的到期日相近，就推定需要按 G1 規則重簽。
PKG 與已公證應用：影響範圍不同
Apple 已明確區分安裝包與既有已公證 Mac 軟體。由受影響證書簽署的安裝套件（PKG），自 2027 年 2 月 1 日起將無法安裝；已簽名、公證並帶有安全時間戳的既有 Mac 軟體，則可繼續運作。後續應用程式更新需使用新證書簽名，並在公證時包含安全時間戳。(Apple 對 G1 到期及產物影響的說明)
| 產物或情況 | 應檢查的重點 | 決策 |
|---|---|---|
| 由受影響證書簽署的 PKG | Developer ID Installer 身份及證書鏈 | 在截止日前以正確 G2 身份重簽，並實際測試安裝 |
| 帶安全時間戳的既有已公證 Mac 應用程式 | 是否確為已簽名、公證且帶有安全時間戳 | 不要只因 G1 到期便假定既有版本必須重簽 |
| 尚未發布的應用程式更新 | 新版本使用的 Developer ID Application 身份及公證流程 | 改用替代證書簽名，按發布流程重新驗證 |
| DMG、ZIP 或其他分發形式 | 容器內的應用程式、安裝程式及各自簽名 | 按實際內容和簽名方式逐項檢查，不將 PKG 結論直接套用 |
此處的關鍵不是「所有舊版都重簽」，而是把交付物拆開追蹤。Apple 的公證文件涵蓋應用程式、磁碟映像檔、ZIP 封存與安裝套件等流程；不同容器可能包住不同內容，因此需要核對實際簽名對象與交付形態。(Apple 公證 macOS 軟體文件)
Developer ID Installer 與 G2：重簽時避免換錯身份
G2 不是可不經確認就套用的同一張簽名憑證。建立替代證書時，應依產物用途分別處理 Developer ID Application 與 Developer ID Installer；如果建立流程要求選擇中間證書，Apple 指引是選擇 G2 Sub-CA。選錯中間證書可能使新證書仍由即將到期的 CA 簽發。使用 Xcode 11.4 或更早版本時，Apple 要求先更新，再建立替代證書。(Apple 關於 G2 替代證書與 Xcode 的說明)
實際操作前，發布工程師可依下列步驟檢查：
- 在開發者帳號中盤點 Developer ID Application 和 Developer ID Installer 證書，記錄使用者、用途、發行者與有效期限。
- 在 Keychain Access 開啟團隊實際使用的證書，展開 Issuer Name，核對 Organizational Unit；不要只根據憑證名稱判斷。
- 對照每種產物選擇適當的簽名身份。應用程式簽名和安裝套件簽名不是可互換的類型；Apple 的簽名疑難排解文件也分別指定相應的驗證工具。
- 建立替代證書時，確認中間證書選項為 G2 Sub-CA，並按 Apple 指引處理舊版 Xcode 的升級要求。
- 在隔離的建置工作區安裝證書及對應私鑰，確認 CI 節點實際可使用該身份。不得將私鑰、密碼或憑據輸出至建置日誌。
- 先重簽代表性 PKG 和應用程式，再檢查簽名鏈、公證狀態與目標 Mac 上的安裝或啟動結果；通過驗收後才更新正式流水線。
macOS CI 簽名驗收：成功建置不等於成功遷移
CI 作業回傳成功，只能說明建置命令完成，不足以證明節點選到了預期的 G2 證書，也不能證明交付的 PKG 能在目標 Mac 安裝。常見盲點包括：建置節點仍讀取舊鑰匙圈、流水線引用同名但不同簽發鏈的身份，以及只看公證提交成功、未做產物安裝測試。
驗收時，應在代表性流水線中記錄建置節點、簽名身份、證書發行者、產物檢查結果及目標安裝結果。PKG 可使用 Apple 所列的 pkgutil --check-signature 檢查簽名；應用程式則可依 Apple 的疑難排解指引使用 codesign 驗證。這些檢查用來確認不同類型的簽名，不能以其中一種的通過結果代替另一種產物的驗收。(Apple 簽名與公證疑難排解文件)
代表性流水線的場景案例可以是：一個團隊同時發布拖放安裝的應用程式與 PKG。若只更新應用程式簽名設定，CI 可能仍讓 PKG 沿用舊的 Developer ID Installer 身份；因此要分別保存兩類產物的簽名檢查結果，並在隔離的目標 Mac 上完成安裝測試。這是團隊的驗收設計，不應被誤寫成 Apple 保證的自動檢查。
做法的優點：把證書識別、產物簽名與實際安裝分成可追溯的檢查點，能較早發現身份或鑰匙圈配置錯誤。
需要承擔的工作：要維護測試用建置環境、更新憑據並保留驗收紀錄；只驗證 CI 綠燈或只在開發者本機測試，都不足以證明發布鏈已完成切換。
如果團隊正在整理簽名憑據的存取與保護方式，可一併參考 xcodeops 的資料隱私說明；需要安排獨立建置環境時，也可先查看 Mac 指南，釐清環境選擇與發布前驗收需求。
常見問題 FAQ
G1 到期後，哪些 PKG 需要優先處理？
優先追查由 G1 簽發的 Developer ID Installer 證書簽署的 PKG。到期日期只是初步篩查線索，應核對簽名證書的 Issuer Name 和 Organizational Unit，再檢查實際分發套件。若確認受影響，應在截止日期前以正確的 G2 身份重簽並完成安裝驗證。
怎樣辨認 Developer ID Installer 證書由哪個中間證書簽發？
在 Keychain Access 中檢查團隊使用的 Developer ID Installer 證書，展開 Issuer Name 的 Organizational Unit；Apple Certification Authority 表示先前的 Sub-CA，G2 則表示目前的 Sub-CA。不要把鑰匙圈中中間 CA 的項目當作自己的簽名證書，也不要只比對證書顯示名稱。
已公證的 Mac 應用程式需要因 G1 到期而重簽嗎？
不應一概要求重簽。Apple 指出，帶安全時間戳的既有已公證 Mac 軟體可繼續運作；未來更新則應使用新證書簽名，並為公證流程包含安全時間戳。這項說明針對既有應用程式，不可直接推廣成所有 PKG、DMG 或其他分發容器都不必檢查。
CI 切換 G2 後，如何驗收 PKG 安裝流程？
確認流水線實際使用 G2 簽名身份及配對私鑰後，先用 pkgutil --check-signature 檢查產物，再於隔離的目標 Mac 安裝代表性 PKG。記錄簽名身份、檢查輸出與安裝結果，並分開驗證應用程式產物；憑據不得放入建置日誌。
發布環境選擇：現有建置機與隔離 Mac
若團隊目前共用一台開發用 Mac 作發布節點，主要風險通常不是硬體本身，而是多人共用鑰匙圈時身份難追蹤、建置工作互相排隊，以及測試和正式發布憑據難以清楚隔離。新增本地 Mac 可提高環境控制度，但要自行承擔採購、維護與資產管理；遠端 Mac 則可供團隊先評估隔離建置用途，仍須確認權限設計、憑據管理及產物驗收是否符合內部要求。
Apple 公告於 2026 年 10 月 1 日發布；本文最後更新於 2026 年 10 月 26 日，截止日期、證書辨識方式及產物差異均核對 Apple Developer 公告與支援文件。(Apple Developer 公告)
若要在不碰正式發布流程的情況下驗證新簽名鏈，先以隔離的 Mac 建置環境完成代表性 PKG 和應用程式測試。現有共用節點若難以隔離憑據、環境差異難追蹤或發布時段常被其他工作佔用，可評估租用遠端真實 Mac 作為測試環境；xcodeops 提供的遠端 Mac 租用可作為候選方式，但仍應先依團隊權限與交付要求驗收。若需要確認環境安排，可透過 xcodeops 聯絡頁面了解，再決定是否適合用於正式流程。
常見問題
Developer ID G1 到期後，哪些 PKG 需要優先檢查？
重點是由原 Developer ID Certification Authority 簽發的 Developer ID Installer 證書所簽 PKG，而非所有舊套件。先在 Keychain Access 查看該簽名證書的 Issuer Name 與 Organizational Unit，再用 pkgutil --check-signature 核對實際分發套件；若確認受影響，應以 G2 身份重簽並在目標 Mac 驗證安裝。
如何確認 Developer ID Installer 證書屬於 G1 還是 G2？
在 Keychain Access 選取團隊實際使用的 Developer ID Installer 證書，展開 Issuer Name 查看 Organizational Unit。Apple 說明，顯示 Apple Certification Authority 的證書屬於先前的 Sub-CA；顯示 G2 則屬於目前的 Sub-CA。不要只看證書名稱或鑰匙圈中的中間憑證項目，並以證書本身作判斷。
已公證的 Mac 應用程式在 G1 到期後需要重新簽名嗎？
依 Apple 對既有軟體的說明，已簽名、公證並帶有安全時間戳的既有 Mac 軟體可繼續運作，不必僅因 G1 到期而一律重簽。這不代表後續版本可以沿用舊身份：未來更新應改用替代證書簽名，並在送交公證時包含安全時間戳；PKG 則須按其自身簽名鏈另行處理。
企業 CI 切換 G2 後，怎樣驗收 PKG 安裝流程？
先確認建置節點的簽名身份、私鑰與鑰匙圈確實對應新 G2 證書，再以 pkgutil --check-signature 檢查輸出 PKG 的簽名資訊與時間戳。最後在隔離的目標 Mac 安裝代表性產物，記錄節點、簽名身份、命令輸出及安裝結果；不要把密碼、私鑰或憑據寫入 CI 日誌。
為簽署遷移準備一台專屬遠端 Mac
透過 xcodeops 租用獨享實體 Mac mini，將憑證設定、建置與驗收流程安排在專屬環境中。