Developer ID 憑證 2027 到期怎麼辦？2026 遷移清單

Developer ID 憑證 2027 到期怎麼辦？2026 遷移清單

Apple 於 2026 年 10 月 1 日公告，舊 Developer ID Sub-CA 將於 2027 年 2 月 1 日到期；其簽發的憑證屆時停止工作，受影響憑證簽署的 .pkg 也將無法安裝（Apple 到期公告）。因此，Developer ID 憑證 2027 到期的正確做法是：先核對實際簽發鏈，再分別處理 Mac App 和 .pkg。受影響的 .pkg 應在截止日前以新憑證重簽；已簽名、公證並帶安全時間戳的既有 Mac App，則不必只因這次到期而立即重簽，後續更新改用新憑證。

適合分發獨立 macOS App、需要確認 Developer ID Application 是否受影響的開發者。
也適合維護 .pkg 安裝器、必須安排截止日前重簽驗收的團隊。
若發布作業使用遠端 Mac，還需要核對憑證、私鑰與實際建置帳號。

最後更新於 2026 年 10 月 2 日；資料核實自 Apple 的到期公告、Developer ID 憑證說明，以及開發者帳號內的實際憑證紀錄。後續預計於 2026 年 11 月再次核對；若 Apple 更新公告或截止日期，應同步修訂判斷。

簽發鏈：新舊中間憑證比憑證名稱更關鍵

不是所有 Developer ID 憑證都應直接判定為受影響。應先到 Certificates, Identifiers & Profiles 檢視憑證紀錄，確認到期日與簽發機構，再按 Apple 公布的舊 Sub-CA 到期資訊判斷。Apple 將受影響範圍指向由該舊中間憑證簽發的憑證，而不是所有名稱中含 Developer ID 的項目（Apple 的中間憑證說明）。

核對時至少保留三項資料：憑證的簽發機構與有效期限、Keychain 中對應的簽名身份、實際發布產物的簽名檢查結果。若帳號紀錄與建置機上看到的身份不一致，先確認使用的是哪個 Apple 開發者帳號，以及發布工作實際呼叫哪個憑證；不要因為憑證名稱相似就假定它們來自同一條簽發鏈。

Apple 說明 Developer ID 憑證可在建立時選擇中間憑證選項，並指出新憑證應採用目前的 Developer ID Certification Authority（G2）。建立前先查閱官方憑證建立說明，並檢查選項是否符合現有 Xcode 與發布流程；舊版 Xcode 的相容性也應依 Apple 文件和實際建置結果確認，不宜直接照搬其他專案的操作。

判斷重點：憑證到期日、簽發機構、憑證用途是不同欄位。把它們分開記錄，才能避免將 Developer ID Application 與 Developer ID Installer 混用。

產物影響：Mac App 與 .pkg 的處理邊界不同

Developer ID Application 用於簽署 Mac App；Developer ID Installer 則用於簽署安裝套件。兩者用途不同，受影響產物及需要完成的驗收也不同。Apple 表示，既有已簽名、公證並帶安全時間戳的 Mac 軟體可繼續運作，後續更新應使用新憑證；受舊中間憑證影響的 .pkg，則應在公告的截止日前以新憑證重簽（Apple 的憑證影響說明）。

公證和安全時間戳不是同一件事：公證是 Apple 對軟體進行的檢查，安全時間戳則與簽名時間相關。換用新憑證也不等於既有 App 必須重新公證。應以實際產物、公證紀錄及 Apple 對受影響範圍的說明作判斷；公證相關問題可另查Apple 的公證問題排查文件。

驗收維度 Mac App：Developer ID Application .pkg：Developer ID Installer
優先核對 簽名身份、簽發鏈、公證與安全時間戳 套件簽名身份、簽發鏈及實際安裝驗收
已發布產物的判斷 若已簽名、公證並帶安全時間戳，不因本次到期一律重簽 若由受影響憑證簽署，列入截止日前重簽清單
後續發布 更新改用新憑證，檢查新版本產物 使用新 Developer ID Installer 憑證重新簽署
驗收證據 簽名檢查結果、公證紀錄、分發包 套件簽名檢查結果、安裝測試、既有發布渠道檢查

這項區分直接影響排程：Mac App 的重點是讓後續更新切換到新身份；受影響的 .pkg 則需優先安排重新簽署和安裝器驗收。Apple 對 .pkg 在截止日後的安裝邊界已有說明，但不應自行推斷所有使用者端環境、快取或傳送渠道都會呈現相同狀況；要以實際重簽產物和部署方式驗收。

簽名身份：證書與私鑰必須在發布帳號中配對

憑證建立完成，不代表建置機已能用該身份簽名。Keychain 中必須有與憑證相配的私鑰，且實際執行建置的使用者帳號能使用該簽名身份。這一點在遠端 Mac 上特別容易漏查：管理者登入時可見的身份，不一定也能由持續整合工作使用。

可在實際發布帳號下執行下列命令，檢視可用的程式碼簽名身份：

security find-identity -v -p codesigning

示意輸出如下，實際名稱與識別碼會依帳號而異：

1) <identity hash> "Developer ID Application: <team name>"
   1 valid identities found

這個結果適合做初步檢查，不能代替對最終產物的驗收。還要確認發布工作使用的簽名身份與預期一致，而且憑證和私鑰位於建置工作可存取的 Keychain。發布記錄可保留身份名稱、產物版本、執行結果及時間；不要輸出私鑰、憑證密碼或可重用的認證資料。

產物驗收：用實際交付檔案取代「憑證已建立」

可按下列檢查項目完成遷移，不需把所有發布工作一次停下來：

  1. 盤點憑證。 在開發者帳號中記錄 Developer ID Application 和 Developer ID Installer 的到期日、簽發機構及狀態。只把能確認由舊 Sub-CA 簽發的項目列為受影響對象。
  2. 分開整理產物。 列出目前分發中的 Mac App、下一版更新，以及仍在提供下載的 .pkg。為每項產物記錄所用簽名身份與公證狀態，不以檔名或版本標籤代替檢查。
  3. 建立新簽名身份。 依 Apple 的 Developer ID 建立說明選擇憑證與中間憑證選項。確認新憑證的簽發機構為目前使用的 G2，並在實際 Xcode 版本與建置環境中試簽。
  4. 驗證私鑰和發布帳號。 在本機或遠端 Mac 的實際建置帳號下執行 security find-identity，確認預期身份可用。若使用多個工作帳號，逐一檢查，不要只驗證管理者帳號。
  5. 檢查 Mac App 簽名。 對候選 App 執行簽名驗證，並核對簽名身份及公證紀錄。Apple 的程式碼簽名憑證技術說明可作為理解簽名憑證資訊的參考。

bash codesign --verify --strict --verbose=2 "MyApp.app" codesign -dv --verbose=4 "MyApp.app" 2>&1

第一條用來驗證簽名；第二條檢視簽名細節。這些命令不會單獨證明 App 已完成公證，也不能取代實際啟動或發布驗收。

  1. 重新簽署並測試 .pkg。 若安裝包使用受影響的 Developer ID Installer 憑證簽署，應在截止日前以新身份重簽。對重簽後的實際檔案檢查簽名，再按發布支援的 macOS 版本和交付方式執行安裝測試。
  2. 留存發布證據。 分別記錄 Mac App 更新與 .pkg 的簽名、公證或安裝結果，並確認既有下載頁、更新程式或其他發布渠道提供的是新產物。憑證建立成功不是遷移完成的判準。

例如，可用以下命令檢視套件簽名：

pkgutil --check-signature "MyInstaller.pkg"

示意輸出應包含簽名狀態及簽名者資訊；實際輸出以本機檢查為準。若命令結果與預期身份不符，先停止發布並查明建置流程選取的憑證，不要把未驗收的安裝包推送到既有渠道。

注意：新憑證可用，不代表舊安裝包已自動換簽。每個仍在分發的 .pkg 都要以實際檔案確認；也不要為了處理憑證到期，直接推定所有既有 Mac App 都必須重簽或重新公證。

常見問題：按影響範圍，而非憑證名稱判斷

舊 Sub-CA 到期是否影響每一個既有 Mac App？
不一定。Apple 明確指出，已簽名、公證並帶安全時間戳的既有 Mac 軟體可繼續運作。仍應檢查實際簽發鏈和公證紀錄；未來更新則改用新憑證。

Developer ID Installer 簽署的 .pkg 何時需要重簽？
若確認由受影響憑證簽署，應在 2027 年 2 月 1 日前以新憑證重簽並完成安裝驗收。Apple 指出該日起這類 .pkg 將無法安裝，詳情以到期公告為準。

已公證且帶安全時間戳的 Mac App 要不要重新簽名？
不必只因本次到期而一律重簽。Apple 說明這類既有軟體可繼續運作；但後續更新應改用新憑證，並針對新的交付產物驗收簽名與公證狀態。

怎樣確認 Developer ID 憑證是不是舊 Sub-CA 簽發？
先在 Certificates, Identifiers & Profiles 查看該憑證的到期資訊和簽發機構，再與 Keychain 中的身份及產物檢查結果交叉比對。必要時參考Apple 的中間憑證說明；不要只靠憑證名稱判斷。

發布環境：本機流程與遠端 Mac 各有驗收責任

若簽名只在一台本機 Mac 執行，遷移範圍較集中，但建置環境可能依賴特定登入帳號、Keychain 和手動操作；多人輪流發布時，簽名身份也較難維持一致。改用遠端 Mac 並不會自動解決憑證或私鑰問題，仍須確認建置帳號可取用正確身份，並在產物層完成簽名及安裝驗收。

小型團隊可先列出以下證據，再決定是否將發布工作搬到獨立環境：

  • 帳號內的憑證紀錄，能辨認舊簽發鏈與新身份。
  • 實際建置帳號可用的簽名身份清單，沒有只存在於管理者帳號的身份。
  • 新版 Mac App 的簽名與公證結果，以及重簽 .pkg 的簽名、安裝和發布渠道驗收。
  • 脫敏後的發布記錄，可追溯所用身份與交付產物，但不含私鑰或可重用憑據。

如果仍在比較部署成本，可參考SFTPMAC 的遠端 Mac 方案與價格資訊。評估時要把環境維護、憑證管理和發布驗收納入，而非只比較是否有一台 Mac。

若目前依賴個人電腦直接簽名，主要風險是發布環境綁定單一帳號、簽名身份難以重現，以及 .pkg 可能未在截止日前完成重簽驗收。對需要在遷移期間保留獨立 macOS 發布環境的小團隊，遠端 Mac 可作為本機以外的選項；它不會取代安全的私鑰管理，也未必適合長期固定負載或必須直接連接實體設備的工作。可先了解 SFTPMAC 的遠端 Mac 使用方式，再按證書、私鑰、工具鏈及交付方式核對是否符合發布流程。