Developer ID Certification Authority 將於2027年2月1日到期

Apple 於2026年10月1日宣布，原始的 Developer ID Certification Authority 將於2027年2月1日到期，而以它所核發之憑證簽署的安裝套件，從那天起「will no longer install」（將無法再安裝）。 經過公證的 App 不受影響：「Previously signed and notarized Mac software (with a secure timestamp) will keep working.」（先前已簽署並經過公證、且帶有安全時間戳記的 Mac 軟體，會繼續正常運作。）¹ 取而代之的授權單位 G2 自2022年1月27日起就開始核發憑證，但 Apple 一直為使用舊版 Xcode 的團隊保留原始授權單位的選項，因此同一個團隊可能兩邊各持有一張憑證。²³ Apple 的判斷依據是憑證簽發者名稱（issuer）中的 Organizational Unit，而不是到期日。

下文依序說明：從鑰匙圈、安裝套件與 App 讀出這項資訊的指令；這些指令在我自己 Mac 上的 66 個 Developer ID App 與四個安裝程式上印出了什麼（其中 49 個 App 與全部四個安裝程式都串連到即將到期的原始授權單位）；Apple 公告裡有一句話與我能檢查到的憑證對不上；以及我會採取的重新簽署順序。⁴

重點摘要

• 日期。 原始授權單位的憑證在2027年2月1日 22:12:15 UTC 到期，距離它生效的那一刻剛好十五年，分秒不差。Apple 的說法：「Certificates issued by this authority will stop working on that date.」（此授權單位核發的憑證將於當天停止運作。）¹⁴
• 安裝套件會停擺，經過公證的 App 不會。 「.pkg files signed with an affected certificate will no longer install」（以受影響憑證簽署的 .pkg 檔案將無法再安裝），而帶有安全時間戳記且經過公證的軟體則「will keep working」（會繼續運作）。¹
• 看簽發者。 原始授權單位所核發的憑證，簽發者的 Organizational Unit 是「Apple Certification Authority」；現行授權單位所核發的憑證則是「G2」。Apple 表示，到期日「doesn’t prove which authority issued a certificate」（無法證明憑證是由哪一個授權單位核發）。²
• 一台 Mac 的樣本。 我「下載項目」資料夾中以 Developer ID 簽署的四個安裝程式，全都串連到原始授權單位，其中最新的一個簽署於2025年12月29日。「應用程式」資料夾裡的 66 個 Developer ID App 中，49 個串連到原始授權單位，17 個串連到 G2。⁴
• 到目前為止，憑證過期並沒有擋下帶時間戳記的軟體。 這 49 個 App 中，有六個使用的憑證已在2022年到2026年5月之間過期，還有一個安裝程式的憑證早在2017年就過期了。Gatekeeper 今天仍接受這七者。Apple 的公告則表示，授權單位本身到期之後，安裝套件就不再享有這種待遇。¹⁴
• 一處不一致。 Apple 說 G2 憑證「expire annually」（每年到期）。但我已安裝 App 上的全部 12 張 G2 憑證，以及我自己在2026年5月取得的那張，效期都是五年。兩個頁面都沒有說明一年效期是從何時開始的。¹²⁴

Apple 宣布了什麼？

公告很短，開頭寫道：「The original Developer ID Certification Authority (Sub-CA) expires on February 1, 2027. Certificates issued by this authority will stop working on that date.」（原始的 Developer ID Certification Authority（Sub-CA）將於2027年2月1日到期。此授權單位核發的憑證將於當天停止運作。）¹ 接著是三個步驟：確認是否受影響、建立新憑證、重新簽署。第三步要怎麼做，取決於您發佈的是什麼：

• 安裝套件。 「Starting February 1, 2027, .pkg files signed with an affected certificate will no longer install. Re-sign all packages with your new certificate before this date.」（自2027年2月1日起，以受影響憑證簽署的 .pkg 檔案將無法再安裝。請在此日期之前，以新憑證重新簽署所有安裝套件。）
• Mac App。 「Previously signed and notarized Mac software (with a secure timestamp) will keep working,」（先前已簽署並經過公證、且帶有安全時間戳記的 Mac 軟體會繼續運作）無須採取任何行動；另外「For future updates, sign with your new certificate and include a secure timestamp for notarization.」（日後的更新，請以新憑證簽署，並為公證加上安全時間戳記。）¹

公告連結的說明頁面描述了這對簽署造成的影響：「After that date, certificates issued from the original authority can no longer be used for signing and must be replaced with certificates from the current Developer ID Certification Authority (G2).」（該日期之後，原始授權單位核發的憑證將無法再用於簽署，必須換成現行 Developer ID Certification Authority（G2）核發的憑證。）頁面上也列出「Required role: Account Holder.」（所需角色：Account Holder。）²

App 與安裝套件的這種區分，和 Apple 一向對過期憑證的說法相當接近。關於 App，Apple 的 Developer ID 說明頁面寫道：「As long as your Developer ID certificate was valid when you compiled your app, then users can download and run your app, even after the expiration date of the certificate.」（只要您編譯 App 時 Developer ID 憑證仍然有效，即使憑證過了到期日，使用者仍可下載並執行您的 App。）至於安裝程式，Apple 各頁面的說法並不一致，甚至同一頁面也自相矛盾。同一個說明頁面寫著「Your installer package will only launch if your Developer ID Installer certificate is valid.」（只有在您的 Developer ID Installer 憑證有效時，安裝套件才會啟動。）憑證總覽中的 Developer ID Installer 條目則兩頭都說：使用者「can still install packages that were signed with this certificate as long as the package includes a trusted timestamp」（只要套件帶有可信任的時間戳記，仍可安裝以此憑證簽署的套件），但隔了兩句又說「new installations won’t be possible until you have re-signed your installer package with a valid Developer ID Installer certificate」（在您以有效的 Developer ID Installer 憑證重新簽署安裝套件之前，將無法進行新的安裝）。⁵ 10月1日的公告則完全沒有給安裝套件任何時間戳記的例外。

公告只談到安裝這件事。它沒有說明已經從受影響套件安裝好的軟體會怎樣，也沒有說明透過裝置管理推送的安裝、或以 installer 指令執行的安裝，是否與使用者自行開啟套件受到相同對待。簽署過的磁碟映像檔也完全沒提到。關於第一點，總覽中針對已過期安裝程式憑證的條目寫著「Previously installed apps will continue to run.」（先前已安裝的 App 將繼續執行。）¹⁵

為什麼會有兩個授權單位？

憑證的效期不能超過核發它的授權單位。Apple 2022年的支援頁面把這當成一條規則：「Certificates cannot be issued with a validity period that extends past the intermediate certificate’s expiration date.」（核發的憑證，其效期不得超過中繼憑證的到期日。）³ 我能找到的每一張2022年以前的 Developer ID 憑證，效期都是五年；因此從2022年2月起，只剩五年壽命的原始授權單位，已經無法再核發完整效期的憑證。Apple 的對策是第二個授權單位：「Starting January 27, 2022, the digital certificates you use to sign your software and installer packages on macOS will be issued from the new Developer ID intermediate certificate that expires on September 16, 2031.」（自2022年1月27日起，您在 macOS 上用來簽署軟體與安裝套件的數位憑證，將由新的 Developer ID 中繼憑證核發，該憑證於2031年9月16日到期。）（憑證本身的效期截止於2031年9月17日 00:00:00 GMT，以太平洋時間計算仍是9月16日。）³⁴

原始授權單位並沒有就此下架。對於「running Xcode 11.4 or earlier」（使用 Xcode 11.4 或更早版本）的團隊，Apple 寫道：「the Apple Developer website will continue to offer Developer ID certificates associated with the original intermediate certificate. Newly issued certificates from this intermediate certificate will be valid for less than five years,」（Apple Developer 網站將繼續提供與原始中繼憑證相關聯的 Developer ID 憑證。由此中繼憑證新核發的憑證，效期將少於五年）而這個選項「will be available for at least one year, starting January 27, 2022」（自2022年1月27日起，至少會提供一年）。³

我 Mac 上的憑證，正好呈現了這段歷史的兩個階段。串連到原始授權單位的 49 個 App，共帶有 27 張不同的簽署憑證。其中2022年2月以前核發的五張，效期各為五年；自2022年2月8日起核發的 22 張，則全都在同一秒到期：2027年2月1日 22:12:15 UTC，也就是原始授權單位本身的最後一秒，而其中最新的一張核發於2026年1月15日。G2 推出將近四年之後，原始授權單位仍在核發憑證，而且每一張的效期都比前一張更短。⁴

如何判斷我的憑證是由哪個授權單位核發的？

Apple 的說明頁面從開發者網站談起：「Any certificates expiring on or before February 1, 2027, are likely affected. However, the expiration date alone doesn’t prove which authority issued a certificate.」（任何在2027年2月1日或之前到期的憑證都可能受影響。不過，光看到期日並無法證明憑證是由哪一個授權單位核發的。）它給出的理由是：「A team can hold a certificate from each authority with identical names, such as the same Developer ID Installer entry twice, differing only in expiration date.」（一個團隊可能同時持有兩個授權單位各自核發、名稱完全相同的憑證，例如出現兩次同樣的 Developer ID Installer 項目，差別只在到期日。）Apple 的檢查方式在 Keychain Access 裡：選取憑證後，「expand the Issuer Name field, and review the Organizational Unit field」（展開「簽發者名稱」欄位，查看 Organizational Unit（組織單位）欄位）。顯示「Apple Certification Authority」代表「The certificate was issued from the previous Sub-CA. Replace this certificate.」（此憑證由先前的 Sub-CA 核發，請更換此憑證。）顯示「G2」代表「The certificate was issued from the current Sub-CA. No action needed.」（此憑證由現行的 Sub-CA 核發，無須採取行動。）頁面還附上一則提醒：「Check your own certificate, not the Developer ID Certification Authority entry in your keychain. That entry is the authority itself, and it’s issued by Apple Root CA, whose Organizational Unit is also Apple Certification Authority.」（請檢查您自己的憑證，而不是鑰匙圈裡的 Developer ID Certification Authority 項目。該項目是授權單位本身，由 Apple Root CA 核發，而 Apple Root CA 的 Organizational Unit 同樣是 Apple Certification Authority。）²

同樣的檢查也能在終端機裡完成，對象有三種。

鑰匙圈中的憑證。

security find-certificate -a -c "Developer ID Installer" -p \
  | openssl crl2pkcs7 -nocrl -certfile /dev/stdin \
  | openssl pkcs7 -print_certs -noout

-a 旗標會傳回所有符合的項目；正因為 Apple 提醒過名稱可能完全相同，這一點才格外重要。整條管線會為每張憑證印出一行 subject 和一行 issuer。若要檢查用來簽署 App 的憑證，把名稱換成「Developer ID Application」即可。我的 Mac 上有一張 Developer ID Application 憑證，沒有 Installer 憑證；用系統內建的 /usr/bin/openssl 執行時，它的 issuer 行是 issuer=/CN=Developer ID Certification Authority/OU=G2/O=Apple Inc./C=US。Homebrew 的 OpenSSL 3 印出的欄位相同，只是改以逗號分隔。名稱找不到符合項目時，什麼都不會印出。⁴

您已發佈的安裝套件。

pkgutil --check-signature YourProduct.pkg

輸出會列出簽章狀態、公證狀態、可信任的時間戳記，以及憑證鏈。要看的日期，是第二個項目「Developer ID Certification Authority」底下的那一個。在我的四個安裝程式上，那裡都顯示 Expires: 2027-02-01 22:12:15 +0000。G2 本身的憑證到期日是2031年9月17日（GMT），所以在 G2 底下簽署的套件，那個位置應該會改為顯示這個日期。不過我手邊沒有以 G2 簽署的套件可以確認。⁴

App。 光靠 codesign -dvv 並不夠，因為兩個授權單位的 common name 完全相同，它印出的 Authority= 行無論哪一個授權單位都長得一樣。請把憑證鏈取出來，再讀中繼憑證：

codesign -d --extract-certificates=/tmp/chain. YourApp.app
openssl x509 -inform DER -in /tmp/chain.1 -noout -subject -enddate

對我「應用程式」資料夾中一個以 G2 簽署的 App 執行時，第二道指令會在 subject 中印出 OU=G2，並印出 notAfter=Sep 17 00:00:00 2031 GMT。對一個在原始授權單位底下簽署的 App 執行時，則會印出 OU=Apple Certification Authority 與 notAfter=Feb 1 22:12:15 2027 GMT。⁴

一台 Mac 上的軟體呈現出什麼？

安裝程式。 我的「下載項目」資料夾裡有四個以 Developer ID 簽署的安裝套件，來自兩家廠商，四個全都串連到原始授權單位。其中三個出自同一家廠商，分別簽署於2025年9月28日、12月14日與12月29日，使用的安裝程式憑證核發於2022年4月13日，於2027年2月1日到期。也就是說，這家廠商在九個月前仍在原始授權單位底下簽署安裝套件。第四個簽署於2014年2月，所用憑證已於2017年3月29日過期。⁴

Gatekeeper 的安裝評估 spctl -a -t install -vv 今天把四個都判定為「Notarized Developer ID」而予以接受，包括簽署憑證在九年前就已過期的那一個。這個結果符合憑證總覽安裝程式條目中關於可信任時間戳記的那句話，而不符合同一條目中「new installations won’t be possible」（將無法進行新的安裝）那句話，也不符合 Developer ID 說明頁面。這也正是 Apple 公告所說、在2月1日對安裝套件終止的那種行為。我無法在10月測試2月的情況，所以那天會發生什麼事，是 Apple 的說法，而不是我的觀察。¹⁴⁵

App。 我「應用程式」資料夾中以 Developer ID 簽署的 66 個 App 裡，49 個串連到原始授權單位，17 個串連到 G2。66 個簽章全都帶有安全時間戳記。Gatekeeper 將其中 63 個回報為「Notarized Developer ID」，也就是 Apple 所說會繼續運作的那種組合：原始授權單位底下 49 個中的 46 個，以及 G2 底下的全部 17 個。其餘三個都在原始授權單位底下：兩個評估失敗，錯誤訊息是「a sealed resource is missing or invalid」，這是關於套件組合（bundle）內容的錯誤；另一個簽署於2018年7月，被接受為未經公證的 Developer ID。Apple 那句話涵蓋的是經過公證的軟體，對於最後這種 App 會怎樣，公告並沒有交代。¹⁴

49 個中有六個使用的憑證，在2026年10月1日之前就已過期，最早的在2022年8月，最晚的在2026年5月。Gatekeeper 六個全都接受，其中五個被判定為經過公證。Apple 對 App 的規則，也就是簽署當下憑證有效即可，已經在我日常使用的軟體上發揮作用。⁴⁵

公告中哪一句話對不上？

公告談到 G2 時寫道：「This certificate authority is valid until 2031, but the certificates issued by the certificate authority expire annually and must be renewed each year.」（此憑證授權單位的效期到2031年，但它核發的憑證每年到期，必須每年更新。）說明頁面的說法相同：「Certificates issued from G2 are valid for one year and must be renewed annually.」（G2 核發的憑證效期為一年，必須每年更新。）¹²

我能檢查到的 G2 憑證，並不是一年期的憑證。我 Mac 上 17 個以 G2 簽署的 App，共帶有 12 張不同的簽署憑證，核發時間介於2023年2月與2026年5月29日之間，每一張的效期都是五年。其中三張核發於2026年4月與5月。我自己的 Developer ID Application 憑證核發於2026年5月10日，到期日是2031年5月11日。⁴

兩個頁面都沒有說明一年效期從何時開始，而我在公告發布後也還沒有建立過憑證，所以無法告訴您今天核發的憑證會是什麼效期。建議以每年更新為前提做規劃，並以您實際拿到的那張憑證上的日期為準。如果從此以後一年期憑證成為常態，那麼 Apple 各頁面之間（以及總覽同一條目之內）對於已過期安裝程式憑證的分歧，就會變得更加重要：若關於可信任時間戳記的那句話成立，套件的壽命就會比憑證長；若其他說法成立，就不會。我手上唯一的資料點，是上面那個2014年的套件，Gatekeeper 至今仍接受它。這幾句話之間孰輕孰重，是我的解讀，不是 Apple 的說法。

我會依什麼順序處理？

1. 盤點。 針對兩種憑證類型各執行一次鑰匙圈檢查，並對每一個您仍提供下載的安裝套件（包括舊版本）執行 pkgutil --check-signature。這項套件檢查也適用於其他廠商的安裝程式；您的團隊若有部署第三方安裝程式，就能藉此找出哪些需要請廠商提供重新簽署的 build。
2. 更換。 如果簽發者顯示「Apple Certification Authority」，請建立一張 G2 憑證。說明頁面的步驟寫道，如果系統要求您選擇「Developer ID Certificate Intermediary」（Developer ID 憑證中繼單位），請選「G2 Sub-CA (Xcode 11.4.1 or later)」，因為「Any other option might issue a certificate from the expiring Certificate Authority」（選擇其他任何選項，都可能從即將到期的憑證授權單位核發憑證），而公告也提醒「Choosing another option may issue a certificate that also expires in 2027」（選擇其他選項，可能會核發同樣在2027年到期的憑證）。如果您兩種類型都有，請「repeat these steps for each, since one certificate does not cover the other」（針對每一種重複這些步驟，因為一張憑證無法涵蓋另一種）。公告還附加了一個前提：「If you’re using Xcode 11.4 or earlier, update before creating your new certificate.」（如果您使用的是 Xcode 11.4 或更早版本，請先更新，再建立新憑證。）¹²
3. 在舊憑證失效前先測試。 Apple 的說法：「Because you can hold up to five Developer ID Application and five Developer ID Installer certificates at a time, you can create and test a replacement before your current certificate expires.」（由於您最多可同時持有五張 Developer ID Application 憑證與五張 Developer ID Installer 憑證，因此可以在目前的憑證到期前，先建立並測試替代憑證。）²
4. 重新簽署安裝套件。 productsign 的手冊寫道：「If you run productsign on a product archive that was previously signed, the existing signature will be replaced,」（如果您對先前已簽署過的 product archive 執行 productsign，既有的簽章將被取代）並指出可信任的時間戳記「is enabled by default when signing with a Developer ID identity」（以 Developer ID 身分簽署時預設為啟用）。它也會嵌入「any intermediate certificates that are found in the keychain」（在鑰匙圈中找到的任何中繼憑證），所以 G2 中繼憑證應該先放進鑰匙圈（手冊中的 --cert 選項是以 Common Name 指定中繼憑證，而兩個授權單位的 Common Name 相同，所以我不會依賴它在兩者之間做選擇）：Apple 2022年的頁面說，Xcode 13.2 或更新版本會自動下載它，否則「you can download it from the Certificate Authority page」（您可以從 Certificate Authority 頁面下載）。把上面的鑰匙圈管線換成名稱「Developer ID Certification Authority」執行，就能列出一台 Mac 上有哪些授權單位；我的 Mac 兩個都有。接著再對結果重新公證並裝訂（staple）一次。公證這一步是我的解讀，而不是 Apple 的原話：重新簽署過的套件已經是另一個檔案。我沒有 Developer ID Installer 憑證，所以這一步我沒有實際跑過。³⁴
5. 檢查結果。 對重新簽署的檔案執行 pkgutil --check-signature，授權單位底下應該不會再出現2027年的日期，而 spctl -a -t install -vv 應該仍然顯示「Notarized Developer ID」。
6. 讓 App 簽章持續帶有時間戳記。 安全時間戳記是 Apple 點名讓軟體能繼續運作的那項屬性，而它對接下來該怎麼做的指示是「sign with your new certificate and include a secure timestamp for notarization」（以新憑證簽署，並為公證加上安全時間戳記）。¹

這個期限是本季第二項與安裝程式有關的變更。第一項就在 macOS 27 本身：未指定主機架構的安裝套件，現在預設為 arm64；Golden Gate 文章說明了這會影響哪些套件，反正都要重新簽署安裝程式的團隊，可以一次把兩件事都檢查完。macOS 27 發行說明文章整理了這個版本中與 Mac 開發者相關的其餘內容；Xcode 27 文章與 Intel 文章涵蓋工具鏈方面的變化；跨團隊容器文章談的是一項會讓已發佈的 Mac App 在讀取時直接失敗、而且不跳出任何提示的變更；ld64 文章則說明兩項會讓 Mac build 中斷的工具鏈變更。

常見問題

Developer ID Certification Authority 何時到期？

2027年2月1日。原始授權單位的憑證在當天 22:12:15 UTC 到期。現行授權單位 G2 則在2031年9月到期；Apple 的支援頁面寫的是9月16日，而憑證本身顯示的是9月17日 00:00:00 GMT。¹³⁴

我的 Developer ID App 會在2027年2月1日無法啟動嗎？

對於經過公證、並以安全時間戳記簽署的軟體，Apple 的答案是不會：它「will keep working」（會繼續運作），無須採取任何行動。簽章帶有時間戳記時，codesign -dvv YourApp.app 會印出一行 Timestamp=；對於經過公證的 App，spctl -a -t exec -vv YourApp.app 會回報「source=Notarized Developer ID」。¹⁴

在原始授權單位底下簽署的 .pkg 安裝程式會怎樣？

Apple 的說法：「Starting February 1, 2027, .pkg files signed with an affected certificate will no longer install. Re-sign all packages with your new certificate before this date.」（自2027年2月1日起，以受影響憑證簽署的 .pkg 檔案將無法再安裝。請在此日期之前，以新憑證重新簽署所有安裝套件。）¹

如何檢查安裝套件是由哪個授權單位簽署的？

對它執行 pkgutil --check-signature，查看憑證鏈中「Developer ID Certification Authority」項目底下的日期。顯示 Expires: 2027-02-01 22:12:15 +0000 就是原始授權單位。⁴

G2 憑證的效期是一年還是五年？

Apple 的公告與說明頁面都說是一年。我在2026年10月1日能檢查到的每一張 G2 憑證（最新的一張核發於2026年5月29日），效期都是五年。兩個頁面都沒有說明一年效期從何時開始。¹²⁴

團隊中誰可以建立替代憑證？

說明頁面列出「Required role: Account Holder.」（所需角色：Account Holder。）²

資料來源