Your Mac App's Developer ID Certificate May Stop Working Feb 1, 2027: A 15-Minute Fix

If you ship Mac software outside the Mac App Store, there's a date to put in your calendar: February 1, 2027.

On October 1, 2026, Apple announced that the original Developer ID Certification Authority (Sub-CA) expires on that date, and that "certificates issued by this authority will stop working on that date." The replacement authority, Developer ID Certification Authority (G2), is valid until 2031.

The good news is that this isn't an emergency for most apps already out there. The bad news is that one kind of file, the .pkg installer, really will break if you do nothing. Here's a short runbook.

What breaks and what keeps working

According to Apple's notice:

• Installer packages (.pkg) break. Starting February 1, 2027, .pkg files signed with an affected certificate will no longer install. Apple says to re-sign all packages with your new certificate before then.
• Already-shipped, notarized Mac apps keep working. Previously signed and notarized Mac software that has a secure timestamp keeps working, with no action needed.
• Future updates need the new certificate. Sign new releases with your G2 certificate and include a secure timestamp for notarization.
• The old certificate can't sign anything after the deadline. Apple's help page says certificates from the original authority "can no longer be used for signing" after February 1, 2027.

One practical consequence: switching your build machine to a new certificate doesn't fix old installers that are still sitting on your download page or in a customer's deployment tool. Those files have to be re-signed and re-uploaded.

Step 1: Check whether you're affected (3 minutes)

Apple's suggested first pass is in Certificates, Identifiers & Profiles:

• Click Certificates and look at your Developer ID Application and Developer ID Installer certificates.
• Any certificate expiring on or before February 1, 2027 is likely affected.

Apple warns that the expiry date alone doesn't prove which authority issued a certificate. To be sure, check the issuer in Keychain Access:

• Select your own Developer ID certificate.
• Expand Issuer Name and look at Organizational Unit.
• Apple Certification Authority means it came from the old Sub-CA, so replace it.
• G2 means it came from the current Sub-CA, so no action is needed.

A common trap Apple calls out: check your certificate, not the "Developer ID Certification Authority" entry in your keychain. That entry is the authority itself, and its Organizational Unit also reads "Apple Certification Authority".

Command-line check (optional)

Apple's help page only describes the Keychain Access check. If you'd rather use Terminal, these standard macOS tools show the same issuer field. They're my own suggestion, not from Apple's notice.

For certificates in your keychain (the name is an example; use your own):

security find-certificate -c "Developer ID Installer: Example Corp" -p | openssl x509 -noout -subject -issuer -enddate

Look for OU=G2 or OU=Apple Certification Authority in the issuer line. If you have several certificates with the same name, add -a to security and inspect each one, because openssl only reads the first.

For a signed app, extract the certificates it was signed with and inspect the leaf:

cd "$(mktemp -d)"
codesign -d --extract-certificates /path/to/YourApp.app
openssl x509 -inform DER -in codesign0 -noout -subject -issuer

For a .pkg, this shows who signed it, whether it has a trusted timestamp, and the certificate chain:

pkgutil --check-signature /path/to/YourInstaller.pkg

Note that codesign -dvvv and pkgutil print the intermediate as "Developer ID Certification Authority" for both the old and G2 authorities, so the name alone won't tell you which one you have. The openssl issuer check is the reliable one.

Step 2: Create a G2 replacement (5 minutes)

You need the Account Holder role for this, according to Apple's help page.

1. Sign in to Certificates, Identifiers & Profiles.
2. Click Certificates, then the + button.
3. Under Software, choose Developer ID Application or Developer ID Installer. If you use both, repeat the steps for each, because one doesn't cover the other.
4. If asked for a Developer ID Certificate Intermediary, choose G2 Sub-CA. Apple says any other option might give you a certificate from the expiring authority. That would be a brand-new certificate that still dies in 2027.
5. Create a certificate signing request, upload it and download the certificate.
6. Double-click it to install it in your keychain.

A few details worth knowing:

• Update Xcode first if it's old. Apple says to update if you're on Xcode 11.4 or earlier. The G2 option needs Xcode 11.4.1 or later.
• You can overlap old and new. A team can hold up to five Developer ID Application and five Developer ID Installer certificates at once, so you can create and test the replacement before retiring the old one.
• G2 certificates last one year. The authority runs until 2031, but each certificate it issues expires annually. Add a renewal reminder now.

Step 3: Re-sign based on what you ship (5 minutes, plus build time)

If you distribute .pkg installers, re-sign every package you still offer, including older versions customers or IT admins may still download. productsign with a timestamp is one way (the identity and file names are examples):

productsign --sign "Developer ID Installer: Example Corp (TEAMID1234)" --timestamp unsigned.pkg signed.pkg
pkgutil --check-signature signed.pkg

If your package contains an app or other code, that code must be signed with your Developer ID Application certificate, and the result should be notarized and stapled as usual. Then replace the old file everywhere it's hosted.

If you distribute apps (.app, .dmg, .zip), you don't need to redo past releases if they were notarized with a secure timestamp. For your next release:

codesign --force --options runtime --timestamp --sign "Developer ID Application: Example Corp (TEAMID1234)" YourApp.app
xcrun notarytool submit YourApp.zip --keychain-profile "example-profile" --wait
xcrun stapler staple YourApp.app

--timestamp adds the secure timestamp Apple's notice mentions, and --options runtime enables the Hardened Runtime that notarization requires. In Xcode, archiving and exporting with "Developer ID" distribution handles this once the new certificate is selected.

Step 4: Don't forget CI (2 minutes per pipeline)

This is where teams usually get caught, because a CI secret quietly keeps signing with the old certificate.

• GitHub Actions or any CI that imports a .p12: export the new certificate and its private key from Keychain Access as a .p12, then replace the secret your workflow imports. Check whether your signing step names the identity with a hash or a full name. The new certificate has a different SHA-1 hash, and you may have two certificates with the same name for a while.
• fastlane match: if you store Developer ID certificates with match (for example type: "developer_id"), the repo still holds the old certificate. Generate the G2 one, get it into your match storage, and confirm your lanes pick it up. Be careful with nuke-style cleanup commands while other projects still depend on the old certificate.
• Self-hosted Mac runners: remove the old identity from the build keychain once the new one is working, so codesign can't accidentally choose it.
• Verify the artifact, not the config: run the openssl issuer check from Step 1 on a build CI actually produced.

Notarization gotchas

• No timestamp, no safety net. Apple's "keeps working" promise covers notarized software with a secure timestamp. Builds signed without one aren't covered by that statement, so treat them as at risk and ship a re-signed update.
• Re-signing invalidates notarization. Any time you re-sign an app or package, submit it to notarization again and staple the new ticket.
• Sign inside out. Nested frameworks, helpers and command-line tools all need the new identity, not just the top-level bundle.

The 15-minute version

• Check Keychain Access: does your Developer ID certificate's issuer OU say G2?
• If not, create G2 Developer ID Application and/or Installer certificates (choose G2 Sub-CA).
• Re-sign and re-upload every .pkg you still offer before February 1, 2027.
• Point Xcode and every CI pipeline at the new certificate, with --timestamp.
• Set a reminder to renew in a year.

If you'd like a hand auditing a Mac build pipeline or moving signing into CI, get in touch.

About the author: Muhammad Tayyab is a full stack and mobile developer based in Lahore. He builds DripScore, an AI outfit rating app live on the App Store, under dawnapps.co. Find him on GitHub, LinkedIn, and X, or say hello at /#contact.

Sources

• Upcoming expiration of Developer ID Certification Authority (Sub-CA) — Apple Developer News (Oct 1, 2026)
• Replacing Developer ID certificates issued from the previous Sub-CA — Apple Developer Account Help
• Developer ID — Apple Developer
• Notarizing macOS software before distribution — Apple Developer Documentation
• fastlane match documentation