正式發布突然提示簽名憑證需替換，而 CI 仍在產出應用程式或 pkg？
2027 年 2 月 1 日是受舊 Sub-CA 簽發憑證影響之 pkg 的安裝界線；Developer ID 憑證到期後，Mac CI 應先核對頒發機構，再準備 G2 替代憑證、隔離驗證，最後分批切換。Apple 已公布的到期與影響說明
負責 macOS 應用程式或安裝套件簽名發布的工程負責人，可用本文確認舊 Sub-CA 的影響範圍。
負責企業 Mac CI 與發布基礎設施的 IT 或平台工程負責人，可依時間線安排並行驗證、切換與回退。
管理 Apple Developer 團隊憑證與私鑰的帳號負責人，可據此建立憑證盤點和發布准入證據。
盤點 Mac CI 中的憑證與產物
遷移開始時，先建立一份能對應到實際工作與產物的清單，不要只從某台 Mac 的 Keychain 憑證名稱推測影響範圍。Developer ID Application 用於簽署 macOS 應用程式；Developer ID Installer 用於簽署安裝套件。兩者用途不同，應分開盤點與測試。Apple 的憑證類型說明
在每個 Mac CI 節點逐項勾選：
- [ ] 記錄節點、CI 服務帳號、Keychain 位置，以及簽名工作實際讀取的憑證身分。
- [ ] 將 Developer ID Application 與 Developer ID Installer 分開列出，記錄帳號歸屬、憑證詳細資訊及頒發機構。
- [ ] 對應使用該憑證的應用程式、更新版本、pkg、建置工作與發布負責人。
- [ ] 記錄私鑰存放位置及可存取的帳號，確認工作所用身分與人工登入後看到的身分一致。
- [ ] 將正在發布、暫停發布、只用於舊版維護的產物分開標示，避免遺漏低頻工作的簽名路徑。
此清單也應包含憑證匯入與更新方式、工作日誌位置，以及誰有權核准正式發布。若一份工作設定同時簽署應用程式與 pkg，應拆成可各自驗收的任務；否則單一成功結果無法說明兩類產物都已完成遷移。
依頒發機構辨別受影響範圍
Apple 公告指出，原 Developer ID Certification Authority（Sub-CA）將於 2027 年 2 月 1 日到期，由其簽發的憑證屆時停止工作；受影響憑證簽署的 pkg 將無法安裝。公告中的時程與處理邊界 因此，判斷依據應是憑證詳細資訊中的頒發機構，而非檔名、團隊慣用名稱或單看憑證到期日。
| 盤點對象 | 核對重點 | 遷移時的判斷 |
|---|---|---|
| Developer ID Application | 核對憑證用途及頒發機構；對照實際簽署的 macOS 應用程式 | 未公證的舊版本、未來更新及新發布流程應各自確認；帶安全時間戳且已公證的既有軟體，依 Apple 公告可繼續運作 |
| Developer ID Installer | 核對憑證用途、頒發機構及使用中的 pkg 工作 | 受影響憑證簽署的 pkg 在公告所列日期後將無法安裝，須安排使用替代憑證重新簽署及安裝驗收 |
| Apple Distribution | 核對憑證用途，避免與 Developer ID 混淆 | 不應因名稱相近就視為本次 Developer ID Sub-CA 遷移對象 |
表中的處理邊界以 Apple Developer 公告 為準。對於既有應用程式，關鍵條件是「已公證」且「帶安全時間戳」；這不等同於所有舊簽名產物都可以繼續安裝，也不代表後續更新可沿用舊憑證。Apple 指出，未來更新要使用新憑證，並依要求包含安全時間戳。
申請 G2 替代憑證並受控匯入
確認憑證用途與頒發機構後，依 Apple 的 Developer ID 憑證替換指引安排相應替代項目。分別確認 Application 與 Installer 的憑證需求，並核對替代憑證所用中間憑證是否來自 G2 Sub-CA；不要因為已在帳號中建立新憑證，就假設正式 CI 已開始使用它。
Apple 的 Developer ID 憑證建立說明列出建立憑證的流程。實際操作前，應由 Apple Developer 帳號管理者核對目前適用的角色、工具鏈前置條件與憑證數量限制，因為帳號權限與官方指引可能影響可採用的申請方式。不要把舊流程中的操作步驟直接當作目前帳號一定適用的條件。
私鑰應依團隊現行憑證管理流程產生、儲存與授權。先確認哪些 CI 服務帳號必須存取簽名身分，再限制其他帳號的讀取權限；替代憑證尚未完成節點驗收前，不要移除正式工作仍依賴的舊設定。憑證本身、私鑰及簽名結果是不同的管理對象，交接文件也要分別記錄。
在隔離 Mac CI 驗證兩類簽名
在不影響正式發布的節點或工作流程中，分別測試應用程式和 pkg。驗收重點不是操作人員手動簽署成功，而是正式 CI 服務帳號能否使用預期憑證完成整條工作，且輸出可供另一位負責人複核。
應用程式路徑：確認簽署身分和簽名結果，再依團隊發布方式驗證公證與散布。Apple 的公證前準備說明可用來核對提交前要求；若提交失敗，對照常見公證問題指引區分簽名、提交或其他問題。記錄建置識別資料、簽名輸出、公證結果及發布測試結果。
pkg 路徑：確認 Installer 類型憑證是否由預期帳號與工作使用，完成 pkg 簽署後，在隔離測試環境確認安裝行為。保存實際安裝結果與 CI 日誌，避免只以「建置工作回傳成功」作為可發布證明。
決策條件如下：
- 若憑證頒發機構可確認為受影響的舊 Sub-CA，就安排替代憑證，並在隔離流程完成對應產物的驗證；否則保留辨別紀錄，先核對 Apple Developer 帳號中的憑證資訊，不要只靠名稱排除風險。
- 若應用程式符合已公證且帶安全時間戳的條件，就依 Apple 說明處理既有版本，同時把未來更新納入替代憑證驗證；否則先確認其公證與時間戳狀態，再決定是否需要重新簽署。
- 若pkg 安裝驗收、CI 服務帳號權限及日誌證據均符合團隊發布標準，就進入分批切換；否則留在隔離驗證階段，修正憑證選取、Keychain 存取或簽名流程後重新驗收。
常見情況與判斷
怎樣確認憑證是否來自舊 Sub-CA？
查閱憑證詳細資訊中的頒發機構，並以 Apple 替換指引核對；同時記下憑證是 Developer ID Application 還是 Developer ID Installer。名稱及到期日可作為盤點線索，不能代替頒發機構核查。結果不明時，先交由帳號管理者確認，不要把不確定的憑證當成安全或受影響的定論。
已公證且帶安全時間戳的既有應用程式需要重簽嗎？
Apple 表示符合這兩項條件的既有 Mac 軟體會繼續運作，並非一律需要重簽。這項處理方式不應延伸到未公證的應用程式或 pkg；未來更新則須使用新憑證，並按 Apple 要求包含安全時間戳。發布紀錄應保留能證明原版本狀態的資料。
分批切換與發布准入
隔離測試通過後，才把替代憑證導入正式 Mac CI。先明確列出受影響工作、憑證設定、負責人與切換次序，再挑選一組具代表性的發布工作驗收；確認日誌與產物都符合預期後，才擴大套用範圍。不要在同一輪變更中同時改動不相關的建置環境，否則發生問題時難以定位原因。
每批切換前後都應核對：
- [ ] 正式工作指定的憑證身分與隔離測試結果一致。
- [ ] 實際 CI 服務帳號能讀取所需私鑰，其他非必要帳號沒有多餘權限。
- [ ] 應用程式的簽名、公證與散布流程均有對應驗收紀錄。
- [ ] pkg 已完成新憑證簽署及安裝行為測試。
- [ ] 建置日誌、產物識別資料、核准人與切換時間可供事後查核。
- [ ] 回退方式不依賴已失效的憑證繼續簽名；若新流程未通過，暫停相關發布並回到已驗證的工作狀態。
最後的發布准入結論應分別記錄 Application 與 Installer 的影響判斷、替代憑證來源、節點權限、產物測試結果及未完成項目。即使單次建置成功，也不能取代實際公證、散布或 pkg 安裝測試；任何未能證明的項目，都應留在待處理清單，而不是默認通過。
如果現有做法是讓開發者各自保管簽名環境，或讓多種發布工作共用一台未隔離的 Mac，常見問題包括私鑰權限難以稽核、節點設定不一致，以及測試工作與正式發布互相干擾。這不代表所有團隊都應改用租賃：需要長期固定負載或實體介面的情況，仍應評估自購設備。若只是遷移期間需要額外、可隔離的 macOS 簽名驗證環境，可先檢視 RUVCLOUD 的遠端 Mac 服務資訊及方案價格頁，再按實際可取得的環境與交付資料核對是否符合團隊的憑證管理和發布准入要求。
最後更新於 2026 年 10 月 4 日；到期時程、憑證辨識與處理邊界核實自 Apple Developer 公告及Developer ID 憑證替換指引。