Apple 說明，撤銷憑證可能令關聯的 Provisioning Profile 失效；因此，企業 iOS CI 憑證輪替不能只替換 Keychain 內的憑證。Apple 撤銷憑證說明指出，應先核對憑證類型及 Apple Developer 帳號限制，再更新關聯設定檔，在隔離的 Mac CI 節點驗收簽署與交付鏈路，通過後才分批切換生產工作。若懷疑私鑰外洩，則立即按安全事件處置，不應為了維持輪替窗口而延後撤銷。
本文適合負責 Apple Developer 帳號、簽署資產及權限審核的 IT 管理者。
也適合需要安排設定檔更新、節點驗收及生產切換的 iOS CI/CD 平台團隊。
發布與資安負責人可用本文判斷一般輪替和私鑰外洩事件的處置界線。
[ SECTION_01 ] 先盤點現況，再確認輪替範圍
輪替計畫應從現有發布路徑開始，而非先建立新憑證。先選定一條近期成功的流水線作基準，保存建置記錄、簽署結果、匯出設定和實際交付方式。這份基準可用來判斷問題出在憑證、設定檔、CI 節點，還是發布權限。
請逐項記錄：
- 受影響的 App ID、應用程式及對應流水線。
- 每個建置節點使用的憑證類型、有效狀態與私鑰存放位置。
- Provisioning Profile 綁定的 App ID、簽署憑證及授權能力。
- Apple Developer 帳號中負責建立、下載、撤銷憑證及管理設定檔的人員。
- 最近一次成功建置與交付的記錄，以及回退時可使用的既有工作路徑。
不要把 Apple Developer 帳號權限、憑證私鑰、Provisioning Profile 和 CI 節點登入權限視為同一項權限。Apple 的角色與權限說明列出不同帳號角色可執行的管理操作；變更前應逐項確認實際角色能否完成所需工作，而非依職稱推定權限。
輪替範圍也要按發布用途分類。Apple 說明的憑證類型包括 Apple Distribution、開發用途、Developer ID，以及雲端管理的分發憑證；用途和管理方式並不相同。Apple 憑證概覽可作分類依據。App Store 發布、團隊內部測試與 Mac 軟體分發不可混為一談，撤銷或到期的影響必須按實際憑證類型及設定檔狀態核實。
變更前的准入評分
以下是變更審核標準，不是對 Apple 規則的保證：
- 通過：資產、帳號責任人、回退條件和隔離驗收路徑均有記錄。
- 有條件通過：新憑證或設定檔可建立，但無法在不影響正式工作的情況下完成完整驗收；需安排受控維護窗口。
- 不通過：私鑰去向不明、帳號權限不足、現有成功基準缺失，或撤銷影響尚未確認。
未達「通過」或「有條件通過」的明確處置條件時，不要直接改動正式發布工作。
[ SECTION_02 ] 按帳號規則建立新簽署資產
確認憑證類別與帳號現況後，才選擇建立新憑證、輪替現有資產，或採用適用的雲端管理憑證流程。不要假設所有類型都能並行使用，也不要把建立憑證成功等同於發布鏈路已可切換。
Apple 對雲端管理憑證提供獨立的使用及輪替說明，須按其適用條件操作；它不能直接替代所有手動管理的簽署方式。雲端管理憑證文件可供確認相應流程。其他憑證能否建立、並存或輪替，則依憑證類型、帳號狀態及可用名額核實；若帳號不允許安全並行驗證，應改用受控維護窗口，不能承諾無停機切換。
新資產建立時，將私鑰生成及交付納入變更審批。只讓執行簽署所需的人員及節點接觸私鑰，並記錄資產負責人、存放位置和回收方式。不要把私鑰放入一般程式碼庫、建置產物或可被多個工作共用的明文設定。
[ SECTION_03 ] 更新 Provisioning Profile，並確認簽署匹配
更換 Apple Distribution 證書後，不應只更新 Mac 上的 Keychain。要先查明現有 Provisioning Profile 是否仍包含目前要使用的簽署憑證，並核對 App ID、授權能力與發布模式。若新憑證不在該設定檔的有效關聯內，就需要依實際簽署流程更新或重新產生設定檔。
Apple 的App Store 設定檔建立文件說明建立設定檔時涉及的應用程式識別及簽署資產；設定檔編輯與下載文件則列出管理既有設定檔的方式。Apple 另有設定檔更新說明，可用於確認何種更新需要重新處理設定檔。
手動簽署的流水線，應確認新設定檔已下載至預期位置，且工作設定引用正確的檔案。使用 Xcode 管理設定檔的流水線，則應核對實際選用的團隊、簽署身分及建置輸出；不能只看專案設定頁面顯示「自動管理」，就推定 CI 節點已取得最新資產。兩種模式都應檢查建置記錄，避免舊設定檔仍被快取或由其他工作路徑選中。
[ SECTION_04 ] 在隔離 Mac CI 節點驗收完整發布鏈路
正式任務不應作為第一次試驗。選取具代表性的應用及流水線，在不覆蓋現有正式工作的前提下，使用隔離的 Mac CI 節點驗證新憑證。驗收範圍須涵蓋憑證識別、簽署、封存、匯出，以及實際目標交付路徑；只完成編譯，不能證明發布已準備就緒。
依序檢查：
- 建置節點能讀取預期憑證及私鑰，且執行身份符合設計。
- 流水線選用的是新憑證和對應 Provisioning Profile，而非快取中的舊資產。
- 封存與匯出流程完整，簽署結果及授權符合該應用的發布用途。
- 交付所需的發布憑證、帳號權限及目標設定均可正常使用。
- 驗收記錄可追溯到變更單、執行人員、所用資產及回退門檻。
若新舊憑證無法並行測試，應在正式切換前安排受控維護窗口，清楚界定停止條件和回退方案。不要以「建置成功」取代安裝、匯出或目標交付的驗證。
[ SECTION_05 ] 分批切換，再按規則處置舊憑證
只有隔離驗收、變更記錄和回退條件均可審核，才進入生產切換。按應用或流水線分批更改簽署設定，每一批先檢查交付結果與建置記錄，再決定是否繼續。若流水線仍引用舊憑證或舊設定檔，或交付結果與基準不符，便暫停後續切換並執行已核准的回退方案。
新資產完成生產驗收後，再依憑證類型及帳號狀態處置舊憑證、私鑰和快取設定檔。撤銷權限本身也需先核對；Apple 的憑證撤銷權限說明可協助確認誰能執行該操作。撤銷可能影響關聯設定檔，因此要依Apple 撤銷指引確認影響，不能在未掌握依賴項時批量清理。
憑證過期後，如何恢復發布？
先確認失效的是憑證、設定檔還是 CI 節點上的簽署身份，再按原發布用途建立或啟用有效資產，更新關聯設定檔，最後於隔離節點重新驗收封存、匯出和交付。若錯誤只出現在單一節點，還須檢查其 Keychain 與工作身份；不要以重建所有應用資產作為第一步。
疑似私鑰外洩時，應先切換還是先撤銷？
按安全事件處理。先依組織事件程序限制受影響私鑰的使用，辨識涉及的憑證、節點與設定檔，並由具備相應權限的人員依 Apple 規則撤銷；同步安排受影響設定檔修復及新資產驗收。不要為了等待一般輪替完成而保留已疑似外洩的私鑰，也不要假設撤銷不會影響關聯設定檔。
提醒：疑似外洩時，安全控制優先於發布連續性；一般輪替則以隔離驗收和回退準備降低中斷風險。兩種情境不可共用同一套切換門檻。
[ SECTION_06 ] 生產切換前的可勾選清單
- [ ] 已盤點受影響的應用、App ID、流水線、建置節點及發布用途。
- [ ] 已確認憑證類別、Apple Developer 帳號角色與實際操作權限。
- [ ] 已記錄私鑰存放位置、接觸人員及變更審批方式。
- [ ] 已核對 Provisioning Profile 的 App ID、簽署憑證及授權能力。
- [ ] 已在隔離節點驗證簽署、封存、匯出和目標交付。
- [ ] 已設定分批切換的暫停條件、回退路徑及舊資產處置責任人。
- [ ] 若屬疑似外洩，已啟動緊急撤銷與設定檔修復流程，而非等待例行切換。
若目前所有簽署工作都綁在少數本地 Mac 上，團隊需自行承擔硬體採購與維護、不同節點環境漂移，以及測試資產與正式發布資產難以隔離等成本；但長期固定且高負載的生產任務，也未必適合以租用資源替代自有設備。對短期試點或需要額外隔離驗收環境的團隊，可先評估遠端 Mac 節點是否符合內部權限與資安要求，再決定是否承接正式工作。可先參考企業遠端 Mac 節點規劃，再到 NOVAKVM 了解可選方案；若需租用，應先以隔離流水線驗收簽署與交付，不要直接把未驗證環境接入生產發布。