Clarification on Installation of Existing Notarized Installer Packages After February 1, 2027

Code Signing Notarization
RajendranP OP
Created
Replies 2
Boosts 1
Views 616
Participants 2

Hello Apple Developer Support,

We are seeking clarification regarding the impact of the upcoming certificate changes taking effect on February 1, 2027.

Our organization has previously distributed macOS installer packages (.pkg) that were:

• Signed using a Developer ID Installer certificate that chains to the Developer ID Certification Authority intermediate certificate expiring on February 1, 2027.
• Successfully notarized by Apple.
• Signed with a secure timestamp.

We are specifically seeking clarification on the impact of the Developer ID Certification Authority intermediate CA expiration on packages that were signed, securely timestamped, and successfully notarized prior to the expiration date.

We would like to understand how these existing packages will be treated after February 1, 2027.

Questions

  1. Will installer packages (.pkg) that were already signed, timestamped, and notarized before February 1, 2027 continue to install successfully after that date?

  2. Does notarization combined with a secure timestamp allow these previously distributed packages to remain trusted and installable after the certificate changes take effect?

  3. Are software vendors required to re-sign and re-notarize installer packages that have already been distributed if they were signed using certificates affected by this change?

  4. If re-signing is required, does this apply to:
    • Only new packages created after February 1, 2027, or
    • Existing packages that were previously notarized and distributed?

  5. Are there any recommended validation steps to determine whether an existing notarized package will continue to install successfully after February 1, 2027?

Business Impact

We are evaluating whether previously released installer packages signed with Developer ID Installer certificates that chain to the expiring Developer ID Certification Authority intermediate CA will remain deployable for customers after February 1, 2027, and whether any re-signing or re-notarization effort is required for our existing catalog of notarized installers.

Without clarification, we cannot determine whether archived installers will continue to function as expected or whether remediation work is required to preserve the installability of previously released software versions.

Thank you for your guidance. We would appreciate any relevant documentation or recommendations regarding best practices for existing notarized installer packages.

Replies  2
Boosts 1
Views  616
Participants  2
DTS Engineer OP
Apple

For the sake of the folks following along at home, we’re talking about the guidance shared in Upcoming expiration of Developer ID Certification Authority (Sub-CA).

I believe that its discussion of installer packages is incorrect, and as long as your package has a secure timestamp then it should be fine. I’ve been trying to find the time to confirm that one way or the other, but it’s been a struggle. Too many other things to do )-:

Fortunately you can confirm this for yourself:

  1. Find an installer package that uses this expiring CA.
  2. Make sure it’s notarised and stapler.
  3. Copy it to a Mac. I typically use a VM for this sort of thing, so I can restore it a fresh snapshot between each test.
  4. Disable networking on that Mac.
  5. Set the time to something after February.
  6. Try to install the packgae.

I believe it’ll install just fine, but I’d be interested in hearing your experience either way.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

DTS Engineer OP
Apple

So I carved out some time to test this today. My Developer ID Installer signing identity is based on G2, so I couldn’t create my own installer. Instead, I went looking for a third-party one. Here’s what I settled on:

  1. I downloaded the Swift 3.0 toolchain: https://download.swift.org/swift-3.0-release/xcode/swift-3.0-RELEASE/swift-3.0-RELEASE-osx.pkg

  2. I checked its signature:

    % pkgutil --check-signature swift-3.0-RELEASE-osx.pkg 
Package "swift-3.0-RELEASE-osx.pkg":
   …
   Signed with a trusted timestamp on: 2016-09-14 03:34:01 +0000
   Certificate Chain:
    1. Developer ID Installer: Swift Open Source (V9AUD2URP3)
       …
------------------------------------------------------------------------
    2. Developer ID Certification Authority
       Expires: 2027-02-01 22:12:15 +0000
       …
------------------------------------------------------------------------
    3. Apple Root CA
       …

    There are a couple of things to note here:

    • It has a trusted timestamp.
    • The intermediate expires on 2027-02-01, meaning it’s most likely not the G2 one.

  3. This package wasn’t notarised out of the box, so I notarised it myself [1]. That’s not a problem, because you’re allowed to notarise packages you don’t ‘own’.

  4. I then stapled it.

  5. I started a macOS 27.0 VM.

  6. I copied the package to it in a way that sets quarantine.

  7. I shut down the VM.

  8. I disabled networking on the VM.

  9. And booted it back up again.

  10. I double clicked the installer in the Finder.

  11. I clicked the lock icon at the top right of the window. The certificate shows green with the text “This certificate is valid”.

  12. I clicked on the disclosure chevron next to Details. That shows that the leaf certificate’s Issuer Name > Organisation Unit is Apple Certificate Authority, confirming that this was indeed issued by the old intermediate. This is per the guidance in Replacing Developer ID certificates issued from the previous Sub-CA

  13. I installed it successfully.

So far so good. But this just establishes a baseline for this installer package. I still had to actually test things:

  1. I restored the VM to a snapshot taken before I started.
  2. I repeated steps 5 through 9 of the previous process.
  3. Using System Settings I set the time forward by a year, to 2027-11-03.
  4. I double clicked the installer in the Finder.
  5. I clicked the lock icon to confirm that it was still happy with the certificate; it was.
  6. And ran through the installer successfully.

This confirms my expectations here. That is, things are fine if your installer package has a trusted timestamp. However, it’s hardly definitive. For example, it’s possible that you might see some variation on older macOS releases. I’ll continue to dig into this at my end.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] If you repeat this test exactly, you won’t have to notarise the swift-3.0-RELEASE-osx.pkg package because I’ve already done so.