Developer ID Certification Authority Expires Feb 1, 2027

Apple announced on October 1, 2026 that the original Developer ID Certification Authority expires on February 1, 2027, and that installer packages signed with a certificate it issued “will no longer install” from that date. Notarized apps are spared: “Previously signed and notarized Mac software (with a secure timestamp) will keep working.”¹ The replacement authority, G2, has issued certificates since January 27, 2022, and Apple kept offering the original one to teams on old Xcode versions, so a team can hold a certificate from each.²³ Apple’s test is the Organizational Unit in the certificate’s issuer name, not the expiration date.

Below are the commands that read it from a keychain, a package, and an app; what they print for the 66 Developer ID apps and four installers on my own Mac, where 49 apps and all four installers chain to the expiring authority; one sentence in Apple’s notice that the certificates I can inspect do not match; and the order I would re-sign in.⁴

TL;DR

• The date. The original authority’s certificate ends at 22:12:15 UTC on February 1, 2027, fifteen years to the second after it began. Apple: “Certificates issued by this authority will stop working on that date.”¹⁴
• Packages stop, notarized apps do not. “.pkg files signed with an affected certificate will no longer install,” while notarized software with a secure timestamp “will keep working.”¹
• Read the issuer. The issuer’s Organizational Unit is “Apple Certification Authority” on a certificate from the original authority and “G2” on one from the current authority. Apple says the expiration date “doesn’t prove which authority issued a certificate.”²
• One Mac’s sample. All four Developer ID-signed installers in my Downloads folder chain to the original authority, the newest signed on December 29, 2025. Of 66 Developer ID apps in my Applications folder, 49 chain to it and 17 to G2.⁴
• Expiry has not stopped timestamped software so far. Six of the 49 apps are signed with certificates that expired between 2022 and May 2026, and one installer with a certificate that expired in 2017. Gatekeeper accepts all seven today. Apple’s notice says the authority’s own expiry ends that for packages.¹⁴
• One mismatch. Apple says G2 certificates “expire annually.” All 12 G2 certificates on my installed apps, and my own from May 2026, run five years. Neither page says when one-year terms began.¹²⁴

What did Apple announce?

The notice is short. It opens: “The original Developer ID Certification Authority (Sub-CA) expires on February 1, 2027. Certificates issued by this authority will stop working on that date.”¹ Three steps follow: check whether you are affected, create a new certificate, and re-sign. The third step depends on what you distribute:

• Installer packages. “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.”
• Mac apps. “Previously signed and notarized Mac software (with a secure timestamp) will keep working,” with no action needed, and “For future updates, sign with your new certificate and include a secure timestamp for notarization.”¹

The help page the notice links to describes the effect on signing: “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).” It also lists “Required role: Account Holder.”²

The split between apps and packages is close to Apple’s standing guidance on expired certificates. For apps, Apple’s Developer ID help page says: “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.” For installers, Apple’s pages do not agree, even with themselves. The same help page says “Your installer package will only launch if your Developer ID Installer certificate is valid.” The certificates overview’s Developer ID Installer entry pulls both ways: users “can still install packages that were signed with this certificate as long as the package includes a trusted timestamp,” yet two sentences later “new installations won’t be possible until you have re-signed your installer package with a valid Developer ID Installer certificate.”⁵ The October 1 notice gives packages no timestamp exception.

The notice speaks only of installing. It does not say what happens to software already installed from an affected package, and it does not say whether installs pushed by device management or run with the installer command are treated the same way as a package a user opens. Nor does it mention signed disk images. On the first point, the overview’s entry for an expired installer certificate says “Previously installed apps will continue to run.”¹⁵

Why are there two authorities?

A certificate cannot outlive the authority that issued it. Apple’s 2022 support page puts it as a rule: “Certificates cannot be issued with a validity period that extends past the intermediate certificate’s expiration date.”³ Every Developer ID certificate I can find from before 2022 runs five years, so from February 2022 the original authority, with five years left, could no longer issue a full-term one. Apple’s answer was a second authority: “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.” (The certificate itself ends on September 17, 2031 at 00:00:00 GMT, which is still September 16 in Pacific time.)³⁴

The original stayed on offer. For teams “running Xcode 11.4 or earlier,” Apple wrote, “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,” an option that “will be available for at least one year, starting January 27, 2022.”³

The certificates on my Mac show both halves of that history. The 49 apps that chain to the original authority carry 27 distinct signing certificates. The five issued before February 2022 each run five years. The 22 issued from February 8, 2022 on all end at the same second, 22:12:15 UTC on February 1, 2027, which is the authority’s own last second, and the newest of them was issued on January 15, 2026. The original authority was still issuing certificates almost four years after G2 arrived, each one shorter than the one before.⁴

How do I tell which authority issued my certificate?

Apple’s help page starts in the developer portal: “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.” The reason it gives: “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.” Apple’s test is in Keychain Access: select the certificate, “expand the Issuer Name field, and review the Organizational Unit field.” “Apple Certification Authority” means “The certificate was issued from the previous Sub-CA. Replace this certificate.” “G2” means “The certificate was issued from the current Sub-CA. No action needed.” The page adds a warning: “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.”²

The same test runs from a terminal, in three places.

A certificate in your keychain.

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

The -a flag returns every match, which matters because of Apple’s identical-names warning, and the pipeline prints a subject line and an issuer line for each. Swap in “Developer ID Application” for the app-signing certificate. My Mac holds one Developer ID Application certificate and no Installer certificate, and with the system’s /usr/bin/openssl its issuer line reads issuer=/CN=Developer ID Certification Authority/OU=G2/O=Apple Inc./C=US. Homebrew’s OpenSSL 3 prints the same fields separated by commas. A name with no match prints nothing.⁴

A package you have shipped.

pkgutil --check-signature YourProduct.pkg

The output lists the signature status, the notarization status, the trusted timestamp, and the certificate chain. The date to read is the one under the second entry, “Developer ID Certification Authority.” On each of my four installers it is Expires: 2027-02-01 22:12:15 +0000. G2’s own certificate ends on September 17, 2031 (GMT), so a package signed under G2 should show that date there instead. I have no G2-signed package to confirm it with.⁴

An app. codesign -dvv is not enough on its own, because both authorities share one common name and its Authority= lines read the same for either. Extract the chain and read the intermediate:

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

On a G2-signed app from my Applications folder the second command prints OU=G2 in the subject and notAfter=Sep 17 00:00:00 2031 GMT. On an app signed under the original authority it prints OU=Apple Certification Authority and notAfter=Feb 1 22:12:15 2027 GMT.⁴

What does one Mac’s software show?

Installers. My Downloads folder holds four packages signed with Developer ID, from two vendors, and all four chain to the original authority. Three come from one vendor, signed on September 28, December 14, and December 29, 2025 with an installer certificate issued on April 13, 2022 that ends on February 1, 2027. That vendor was still signing packages under the original authority nine months ago. The fourth was signed in February 2014 with a certificate that expired on March 29, 2017.⁴

Gatekeeper’s install assessment, spctl -a -t install -vv, accepts all four today as “Notarized Developer ID,” including the one whose signing certificate expired nine years ago. That result matches the trusted-timestamp sentence in the certificates overview’s installer entry, and not the entry’s “new installations won’t be possible” sentence or the Developer ID help page. It is also the behavior Apple’s notice says ends for packages on February 1. I cannot test February from October, so what happens that day is Apple’s statement, not my observation.¹⁴⁵

Apps. Among the 66 apps in my Applications folder signed with Developer ID, 49 chain to the original authority and 17 to G2. All 66 signatures carry a secure timestamp. Gatekeeper reports 63 as “Notarized Developer ID,” which is the combination Apple says keeps working: 46 of the 49 under the original authority and all 17 under G2. Of the other three, all under the original authority, two fail assessment with “a sealed resource is missing or invalid,” an error about the bundle’s contents, and one, signed in July 2018, is accepted as Developer ID without notarization. Apple’s sentence covers notarized software, and the notice does not say what happens to an app like that last one.¹⁴

Six of the 49 are signed with certificates that had already expired by October 1, 2026, the earliest in August 2022 and the latest in May 2026. Gatekeeper accepts all six, five of them as notarized. Apple’s rule for apps, that a certificate valid at signing time is enough, is already at work on software I use.⁴⁵

Which sentence in the notice does not match?

The notice says of G2: “This certificate authority is valid until 2031, but the certificates issued by the certificate authority expire annually and must be renewed each year.” The help page says the same: “Certificates issued from G2 are valid for one year and must be renewed annually.”¹²

The G2 certificates I can inspect are not one-year certificates. The 17 G2-signed apps on my Mac carry 12 distinct signing certificates, issued between February 2023 and May 29, 2026, and every one runs five years. Three of them were issued in April and May 2026. My own Developer ID Application certificate, issued on May 10, 2026, ends on May 11, 2031.⁴

Neither page says when one-year validity began, and I have not created a certificate since the notice, so I cannot say what a certificate issued today comes back with. Plan for annual renewal, and read the dates on the certificate you are actually issued. If one-year certificates are the rule from here on, the disagreement between Apple’s pages, and within the overview’s own entry, about expired installer certificates starts to matter more: if the trusted-timestamp sentence holds, a package outlives its certificate, and if the others hold, it does not. The one data point I have is the 2014 package above, which Gatekeeper still accepts. How those sentences weigh against each other is my reading, not Apple’s.

What would I do, in order?

1. Inventory. Run the keychain check for both certificate types, and pkgutil --check-signature on every package you still offer for download, old versions included. The package check works on other vendors’ installers too, which is how to find the ones your team deploys that need a re-signed build from the vendor.
2. Replace. If an issuer shows “Apple Certification Authority,” create a G2 certificate. The help page’s steps say that if you are asked to select a “Developer ID Certificate Intermediary,” choose “G2 Sub-CA (Xcode 11.4.1 or later),” because “Any other option might issue a certificate from the expiring Certificate Authority,” and the notice warns that “Choosing another option may issue a certificate that also expires in 2027.” If you hold both types, “repeat these steps for each, since one certificate does not cover the other.” The notice adds a precondition: “If you’re using Xcode 11.4 or earlier, update before creating your new certificate.”¹²
3. Test before the old one goes. 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.”²
4. Re-sign packages. The productsign manual says: “If you run productsign on a product archive that was previously signed, the existing signature will be replaced,” and that a trusted timestamp “is enabled by default when signing with a Developer ID identity.” It also embeds “any intermediate certificates that are found in the keychain,” so the G2 intermediate should be in the keychain first (the manual’s --cert option names an intermediate by Common Name, and both authorities share one name, so I would not rely on it to choose between them): Apple’s 2022 page says Xcode 13.2 or later downloads it automatically, and otherwise “you can download it from the Certificate Authority page.” The keychain pipeline above, run with the name “Developer ID Certification Authority,” lists the authorities a Mac has; mine shows both. Then notarize and staple the result again. The notarization step is my reading rather than Apple’s sentence: a re-signed package is a different file. I hold no Developer ID Installer certificate, so I have not run this step.³⁴
5. Check the result. pkgutil --check-signature on the re-signed file should no longer show the 2027 date under the authority, and spctl -a -t install -vv should still say “Notarized Developer ID.”
6. Keep app signatures timestamped. A secure timestamp is the property Apple names for software that keeps working, and its instruction for what comes next is to “sign with your new certificate and include a secure timestamp for notarization.”¹

The deadline is the second installer change of the season. The first is in macOS 27 itself, where a package that names no host architecture now defaults to arm64; the Golden Gate post covers which packages that touches, and a team re-signing its installers anyway can check both at once. The macOS 27 release notes post has the rest of that release for Mac developers, the Xcode 27 post and the Intel post cover the toolchain side, the cross-team container post covers a change that fails shipped Mac apps at read time without a prompt, and the ld64 post covers two toolchain changes that stop Mac builds.

FAQ

When does the Developer ID Certification Authority expire?

February 1, 2027. The original authority’s certificate ends at 22:12:15 UTC that day. The current authority, G2, ends in September 2031; Apple’s support page gives September 16, and the certificate itself reads September 17 at 00:00:00 GMT.¹³⁴

Will my Developer ID app stop launching on February 1, 2027?

Apple says no for software that was notarized and signed with a secure timestamp: it “will keep working,” with no action needed. codesign -dvv YourApp.app prints a Timestamp= line when the signature has one, and spctl -a -t exec -vv YourApp.app reports “source=Notarized Developer ID” for a notarized app.¹⁴

What happens to .pkg installers signed under the original authority?

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.”¹

How do I check which authority signed a package?

Run pkgutil --check-signature on it and read the date under the “Developer ID Certification Authority” entry in the chain. Expires: 2027-02-01 22:12:15 +0000 is the original authority.⁴

Do G2 certificates last one year or five?

Apple’s notice and help page both say one year. Every G2 certificate I could inspect on October 1, 2026, the newest issued on May 29, 2026, runs five years. Neither page says when the one-year term started.¹²⁴

Who on the team can create the replacement?

The help page lists “Required role: Account Holder.”²

Sources