The Developer ID CA expires on 1 February 2027. Which packages stop installing?

On 1 October 2026 Apple announced that the original Developer ID Certification Authority expires on 1 February 2027, and that installer packages signed through it will no longer install after that. Apps that are already installed keep working. This page sets out what Apple said, how to tell an affected package from a safe one, and which install paths are hit.

Check a .pkg in your browser (the file stays on your computer)

What Apple said

Apple Developer news, Upcoming expiration of Developer ID Certification Authority (Sub-CA), 1 October 2026:

The original Developer ID Certification Authority (Sub-CA) expires on February 1, 2027. Certificates issued by this authority will stop working on that date.

Installer packages (.pkg): 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—no action needed.

The notice makes no secure-timestamp exception for packages. That differs from the usual case, where only the signer's own certificate expires and a timestamped package keeps installing. Here the intermediate authority expires, so the whole chain stops being valid.

Apple's help page, Replacing Developer ID certificates issued from the previous Sub-CA, says to check the issuer rather than the date:

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. To be certain, check the issuer.

The exact moment

The old intermediate certificate's not after time is 2027-02-01 22:12:15 UTC. That is 2:12 pm on 1 February in California (PST), 10:12 pm on 1 February in London, and 9:12 am on 2 February in Sydney (AEDT). Apple's notice says Starting February 1, 2027, so plan to finish before 1 February wherever you are.

Old CA or G2: how to tell

Both authorities are called Developer ID Certification Authority, and both are issued by the same Apple Root CA. They differ in these fields (read from real signatures, and matching Apple's description):

What to look at, in order of reliability:

1. The intermediate's fingerprint or expiry. A package carries its whole chain, so if the chain contains the certificate with SHA-256 7AFC9D01… (expiring 2027-02-01 22:12:15), it is affected.
2. The issuer of the signer's certificate. Organisational unit Apple Certification Authority means the old CA; G2 means the new one. Apple's warning applies: 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.
3. Not the signer certificate's expiry date. Some G2 certificates issued in 2021–22 expired before 2027 and were never affected, and G2 signer certificates with five-year lives exist.

Which install paths fail

Every common way of installing a package on a Mac ends in Apple's installer framework (the installer command or Installer.app), which has refused packages with an expired or untrusted chain in past certificate expiries. So a package signed through the old CA is expected to fail on all of them unless the admin deliberately bypasses the check.

Precedent: when Apple's own installer certificate expired on 24 October 2019, softwareupdate and startosinstall failed with CSSMERR_TP_CERT_EXPIRED and Certificate used to sign package is not trusted, as reported on Jamf Nation at the time.

Check with pkgutil

On any Mac, for one package:

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

pkgutil prints each certificate's name, expiry and SHA-256 fingerprint, but never the organisational unit. Look at the Developer ID Certification Authority entry in the chain:

    2. Developer ID Certification Authority
       Expires: 2027-02-01 22:12:15 +0000      <- old CA: affected
       SHA256 Fingerprint:
           7A FC 9D 01 A6 2F 03 A2 DE 96 37 93 6D 4A FE 68 09 0D 2D E1 8D 03
           F2 9C 88 CF B0 B1 BA 63 58 7F

G2 shows Expires: 2031-09-17 00:00:00 +0000 and a fingerprint starting F1 6C D3 C5.

For a folder of packages (Terminal, zsh or bash), this lists the ones whose chain contains the old CA:

find /path/to/packages \( -name '*.pkg' -o -name '*.mpkg' \) -print0 |
  while IFS= read -r -d '' f; do
    if pkgutil --check-signature "$f" | grep -q '2027-02-01 22:12:15'; then
      echo "OLD CA: $f"
    fi
  done

This catches packages you have on disk. It doesn't look inside disk images or inside other packages, and a package whose chain pkgutil can't build (no network access to Apple's trust services, for example) prints no chain at all, so check anything with an unexpected status by hand.

For your own signing certificate, follow Apple's method: in Keychain Access, select your Developer ID Installer certificate, expand Issuer Name and read the Organizational Unit.

What to do about an affected package

• If you build it: create a new Developer ID Installer certificate and choose the G2 Sub-CA when asked for the intermediary. Apple: Choosing another option may issue a certificate that also expires in 2027. Then re-sign with productsign --sign "Developer ID Installer: Your Name (TEAMID)" --timestamp old.pkg new.pkg, notarize and staple it, and replace the file everywhere it is deployed.
• If a vendor builds it: download their current installer and check it; many vendors re-sign without announcing it. If there's no G2 build yet, send them Apple's notice.
• Interim fix for managed deployment: Jamf policies, Munki and Intune's unmanaged PKG type accept unsigned packages, so stripping the signature (pkgutil --expand, then pkgutil --flatten) keeps them installing. PreStage, InstallEnterpriseApplication and Intune line-of-business apps need a valid signature: re-sign the stripped package with your own G2 certificate.
• Packaging pipelines: make sure AutoPkg recipes and CI jobs sign with the G2 certificate, so new builds don't bring the old chain back.

What is not known yet

• Nobody can observe the cutoff before it happens. The install-path table rests on Apple's notice plus how the installer behaved when earlier certificates expired (2012, 2019, 2020), not on a live test.
• Apple could still ship a grace period or an operating-system change before February. This page will be updated if Apple publishes one.

Sources

• Apple Developer news, Upcoming expiration of Developer ID Certification Authority (Sub-CA), 1 October 2026.
• Apple Developer help, Replacing Developer ID certificates issued from the previous Sub-CA.
• Apple, Developer ID: Your installer package will only launch if your Developer ID Installer certificate is valid.
• Jamf Nation, Use -allowUntrusted to override (January 2020): a Self Service policy failing on an untrusted package certificate.
• Jamf Nation, Heads up: Apple's installer certificate expires today (October 2019).
• Jamf, Creating a signing certificate using Jamf Pro's built-in CA: PreStage enrollment packages signed by an expired certificate must be re-signed.
• Munki wiki, Allowing Untrusted Packages.
• Microsoft Learn, Add a macOS line-of-business app and Add an unmanaged macOS PKG app.
• Installomator, source on GitHub (installFromPKG).
• Howard Oakley, Is that signing certificate still valid? (20 January 2026), on timestamps and expired signer certificates.