Developer ID certificate expiration: re-sign .pkg installers

Apple's announcement of 1 October 2026 reads like a code-signing emergency, and for most Mac teams it is not one. The Developer ID certificate expiration on 1 February 2027 is asymmetric: software you already signed and notarised with a secure timestamp keeps working untouched, while .pkg installers signed by the original Sub-CA stop installing on that date. The job is an inventory, not a rebuild of everything.

Apple's wording is precise, so start from it. "The original Developer ID Certification Authority (Sub-CA) expires on February 1, 2027. Certificates issued by this authority will stop working on that date." Per artefact:

What you ship	On 1 February 2027	What you do
.pkg installer signed by the original Sub-CA	Will no longer install	Re-sign with a new certificate before the date
Mac app already signed and notarised, with a secure timestamp	Keeps working	Nothing now; sign future updates with the new certificate
Developer ID certificate issued by the original Sub-CA	Can no longer be used for signing	Replace it from the G2 authority
Certificate already issued from Developer ID Certification Authority (G2)	Unaffected	Renew it annually, every year

What the Developer ID certificate expiration actually breaks

The distinction worth holding onto is between a signature that has to be validated against a live chain and one that was validated once, at notarisation time, and carries proof of when. Apple's instruction for Mac apps is explicit: previously signed and notarised software with a secure timestamp "will keep working—no action needed". The secure timestamp is what makes that true, which is why it is worth checking that your signing step has always included one rather than assuming it did.

Installer packages get the opposite instruction. From 1 February 2027, a .pkg signed with an affected certificate "will no longer install", and Apple tells you to re-sign all packages before that date. If you distribute a tool, an agent or an internal line-of-business installer outside the Mac App Store, that is the artefact that breaks — including the copy sitting on a customer's file share from eighteen months ago.

How to find out which of your certificates are affected

Apple's replacement guide makes one point that most summaries drop: the expiry date is a hint, not an answer. In Certificates, Identifiers & Profiles, open Certificates in the sidebar and look at your Developer ID Application and Developer ID Installer certificates. Anything expiring on or before 1 February 2027 is likely affected, but Apple warns that expiration date alone does not prove which authority issued a certificate. You have to read the issuer.

In Keychain Access, select your certificate, expand the Issuer Name field and read the Organizational Unit. G2 means the current Sub-CA and no action. Apple Certification Authority means the previous one, and that certificate needs replacing. Apple adds a caveat that catches people: check your own certificate, not the Developer ID Certification Authority entry in the list, because the authority itself is issued by Apple Root CA.

From the command line, the same field comes out of the keychain directly:

security find-certificate -c "Developer ID Installer: Your Company" -p \
  | openssl x509 -noout -issuer -enddate

Run it for each Developer ID identity you hold, Application and Installer — then run it where it matters more, on the build machine. The identity a developer sees in their own keychain is rarely the one that signs releases, and the certificate nobody remembers is usually the one installed on a runner two years ago. If signing happens inside a hosted pipeline, this inventory belongs to whoever owns your CI/CD implementation.

Creating the G2 certificate without accidentally repeating the problem

The replacement comes from the current authority, Developer ID Certification Authority (G2). In Certificates, Identifiers & Profiles, add a certificate, pick Developer ID Application or Developer ID Installer under Software, and repeat for each type you hold. Then upload a certificate signing request and install what comes back.

One step in that flow decides whether the exercise was worth doing. When you are prompted to select a Developer ID Certificate Intermediary, choose G2 Sub-CA. Apple states plainly that choosing another option may issue a certificate that also expires in 2027 — which is to say you can complete the whole migration and end up exactly where you started.

The Xcode requirement is where the two Apple pages read slightly differently, and the difference matters. The announcement says to update if you are using "Xcode 11.4 or earlier". The intermediary picker and the intermediate certificate page both name the threshold as Xcode 11.4.1 or later. Take the stricter reading: 11.4 is on the wrong side of the line. The same page notes that Xcode 13.2 and later downloads the new intermediate automatically when signing, so a modern toolchain needs nothing extra.

Two details make this a rollout rather than a cutover. Apple allows up to five Developer ID Application and five Developer ID Installer certificates at once, so you can issue the G2 replacement and test a signed build with it while the old certificate still works. And keep the existing intermediate installed while you are still signing with existing Developer ID certificates — removing it early breaks the thing you are trying to protect.

Re-signing installers, and proving it worked

For a flat package, re-signing is productsign --sign "Developer ID Installer: Your Company" old.pkg new.pkg. Where you still have the build, rebuilding with productbuild against the new identity is cleaner than re-signing an artefact whose provenance you are guessing at. For the app inside it, sign with codesign --timestamp so the secure timestamp is there, because that is the property Apple ties the "keeps working" guarantee to.

Apple's instruction stops at re-sign. In practice we treat a re-signed installer as a new artefact and put it back through the full path: submit with notarytool, staple the ticket, then verify with spctl -a -vvv -t install new.pkg and pkgutil --check-signature new.pkg on a machine that has never seen the package before. Verifying on the machine that built it tells you almost nothing, which is the same reason a pre-submission checklist is worth more than a developer's confidence.

Annual renewal is the change that outlasts the deadline

This is the line in Apple's announcement to plan around, and it is easy to skim past: the G2 authority "is valid until 2031, but the certificates issued by the certificate authority expire annually and must be renewed each year."

Developer ID certificates from the original Sub-CA ran for years at a stretch, and a renewal you perform once every few years can survive in one person's memory. One you perform every year, for up to ten identities, cannot — and its failure mode is a release that cannot be signed on the morning you needed to ship a fix.

So the useful output of this work is not a re-signed package. It is a pre-flight step in the pipeline that reads the signing identity's notAfter date and fails the build while there is still time to act, plus a dated owner who is not a person's recollection. In the systems we build, expiry dates that can stop a deployment are monitored facts, the same as a certificate on a load balancer — which matters more, not less, when you build without a Mac of your own and the identity lives somewhere nobody looks.

When this does not apply to you

Apple's announcement names Developer ID Application and Developer ID Installer certificates — the ones used to distribute outside the Mac App Store. If the Mac App Store is your only Mac channel, you do not hold a Developer ID certificate and there is nothing here to re-sign. The announcement also says nothing about iOS distribution signing, so do not extend it there on your own authority.

If every certificate you hold already shows G2 as the issuer's Organizational Unit, you are done except for the annual renewal, which is the part people will forget. And note what Apple's text does and does not name: it singles out .pkg installers and Mac apps, and does not call out signed disk images. If you ship a signed .dmg, re-sign it with the new certificate on your next release rather than reasoning by analogy about what Gatekeeper will accept.

Do the small thing this week, because it sizes everything else: list every Developer ID identity across laptops, build servers and hosted runners, read the issuer OU on each, and write down which .pkg artefacts you still expect customers to install after 1 February 2027. That list is the project. If it is longer than you assumed because signing is scattered across machines nobody owns, that is a pipeline problem rather than a certificate one, and untangling it is usually where our mobile and desktop app engineering work starts.