DEVELOPER ID G2 CERTIFICATE EXPIRY
How to Validate Mac CI? 2026

The Mac CI signing job still succeeds, but its Developer ID certificate may come from the expiring authority.

Fastest fix: check the certificate’s Issuer first; replace only certificates issued by the original Sub-CA, then validate signing and notarization in an isolated Mac CI job.

This runbook is for engineers who maintain Developer ID signing, distribution, and notarization for macOS apps. It is also for DevOps engineers responsible for Mac CI keychains and release credentials, plus release owners deciding which packages or apps need action.

Last updated: November 7, 2026. Dates and certificate guidance checked against Apple’s expiration announcement, certificate replacement instructions, and Apple’s Developer ID intermediate certificate information.

Start by separating the affected products

Apple’s announcement says the original Developer ID Certification Authority (Sub-CA) expires on February 1, 2027. Apple directs developers to use the G2 Sub-CA when creating replacement certificates. Do not treat the date alone as proof that every certificate or release artifact is affected: check the issuer of the certificate that the pipeline actually uses. (Apple expiration announcement; Apple’s replacement guide)

The most important release distinction is between the two Developer ID certificate purposes:

• Developer ID Application is used to sign Mac applications.
• Developer ID Installer is used to sign installer packages, including .pkg files.

The expiration announcement does not mean every existing Mac app must be re-signed. Apple says an already notarized app with a secure timestamp does not need re-signing solely because of this Sub-CA expiration. Affected installer packages need separate review and replacement planning. Keep those decisions separate in the release record rather than applying one blanket “re-sign everything” rule. <

Artifact or identity	What to check	Decision for this change
Developer ID Application certificate	Issuer, certificate purpose, selected CI identity	Replace if it was issued by the original Sub-CA; test app signing and notarization.
Developer ID Installer certificate	Issuer and whether a distributed .pkg uses it	Replace if affected; produce and validate a newly signed package before the deadline.
Already notarized Mac app	Signature, notarization result, secure timestamp	Do not re-sign solely for this expiration if Apple’s stated conditions are met.
Untracked or ambiguously signed artifact	Signing identity and release history	Hold distribution until you establish which certificate signed it and whether it is affected.

That distinction is the first acceptance gate: an application certificate and an installer certificate are not interchangeable, and the app exception is not a general exemption for packages.

Step 1: Inventory the certificates your pipeline really selects

Start from the release job, not from an account-wide list of certificates. A developer account can contain identities that are unused, retained for recovery, or referenced by only one legacy workflow. You need to know which identity the active Mac CI job selects, which keychain it searches, and which artifact it signs.

In Certificates, Identifiers & Profiles, record each relevant certificate’s purpose, issuer, and validity. Then compare that inventory with the signing configuration in the repository and CI system: identity names, keychain setup, environment variables, Xcode build settings, scripts, and any stored signing credentials. Avoid recording private key material in the inventory.

On the Mac that can access the certificate, inspect the identity list:

security find-identity -v -p codesigning

Use Keychain Access to inspect the selected certificate’s details. If you have an exported certificate file, OpenSSL can display its issuer and validity:

openssl x509 -in developer-id.cer -inform DER -noout -issuer -dates

If the certificate is already in PEM format, omit -inform DER. Do not identify an authority from the expiry date alone. The required discriminator is the certificate’s Issuer; compare that value with Apple’s information about the original Developer ID Certification Authority and G2. Apple’s certificate creation guide describes the certificate purposes and creation process.

Make an inventory entry for every release path, including manual fallback jobs. For each entry, record:

• Certificate purpose: Application or Installer.
• Issuer and validity dates as shown on the certificate.
• CI workflow, signing command, and keychain used.
• Artifact type and distribution channel.
• Whether the artifact is notarized and has a secure timestamp.

The key operational risk is a false sense of coverage: a new certificate can exist in the developer account while the production job still selects an old identity from a keychain or secret store.

Step 2: Replace the right identity and plan the handoff

Create replacement certificates by purpose. If a workflow signs both an app and a .pkg, verify whether it needs both a Developer ID Application certificate and a Developer ID Installer certificate; do not assume one replaces the other. Follow Apple’s current replacement instructions, choose the G2 Sub-CA as directed, and check the resulting certificate’s Issuer before updating CI.

Treat the private key and its handoff as a separate release task. Confirm who creates or imports the key, which authorized account or process can access it, how the certificate and key reach the signing keychain, and how the old credential is removed or retained for rollback. Do not put a private key in a repository or expose it in job logs. Verify access using the same execution account that runs the release workflow.

Older Xcode or signing-tool environments can make the replacement process less straightforward. Do not infer compatibility from an old pipeline’s success or guess at a minimum version. Check Apple’s current replacement instructions and the tools installed on the Mac that will create and use the certificate. If the portal or tools do not offer the expected G2 path, resolve that before moving the release job; do not silently fall back to an old certificate.

<

Readiness area	Pass	Hold	Fail
Issuer and purpose	Issuer is recorded; Application and Installer uses are mapped separately	Certificate exists, but a job’s selected identity is unclear	Affected issuer remains in a release path with no replacement plan
Keychain access	Intended CI account can access the replacement identity	Access works only in an interactive session	Key or certificate is unavailable to the actual job
Signing and notarization	CI signing, submission, and result checks are captured separately	Only a local manual signing test has passed	Signing or notarization fails, or evidence is missing
Artifact handling	Replacement package or app is verified and linked to its release record	Artifact history is incomplete	An affected package remains queued for distribution after the deadline

Use the table as a release scorecard, not as a certificate compatibility claim. A “Pass” requires evidence from the real workflow. A successful certificate creation or a local signing test alone is not enough.

Step 3: Run an isolated Mac CI acceptance job

Before changing the production release lane, test the replacement identity in a separate job or controlled branch. Keep the execution account, signing settings, keychain behavior, and notarization credentials aligned with production. The goal is to expose differences between an engineer’s interactive shell and the CI process before a release depends on the new identity.

A practical sequence is:

1. Make the replacement certificate and private key available to the isolated job through your approved secret-handling process.
2. Confirm that the job’s execution account can find the expected signing identity. Save the command output without exposing sensitive key material.
3. Sign a representative application using the same build settings and signing command as the release pipeline.
4. Submit the signed app for notarization using the workflow Apple documents for customizing notarization.
5. Record the notarization submission result separately from the signing result. If your process staples a ticket, run the stapling and validation steps used for release.
6. If the pipeline produces installer packages, sign a representative .pkg with the replacement Installer identity and inspect that package independently.
7. Confirm that the job can complete after a clean start, not only after an engineer has manually unlocked or configured a keychain.

For an application, inspect the signature and its details with the checks your release process supports. For a package, verify the package signature with pkgutil --check-signature. For notarization, preserve the submission identifier, status, and final result as separate evidence; Apple’s documentation covers notarizing macOS software before distribution.

If you do not have a Mac available for this controlled run, first establish what access and credential handling your team requires. You can review MACGPU’s remote Mac options as one way to evaluate a Mac environment for release testing. Do not assume that a remote host automatically satisfies your organization’s key custody, network, or compliance requirements; validate those independently.

Step 4: Verify the shipped artifact, not just the job log

A green CI status is evidence that commands returned successfully; it is not a complete artifact acceptance result. Verify the output that will actually reach users, and bind the results to a build identifier or release record.

For a signed application, inspect the signature and confirm that the intended Developer ID identity was used. Confirm the notarization outcome and, where applicable, that the secure timestamp is present. The exception Apple gives for an already notarized, timestamped Mac app applies to that app under the stated conditions; it does not prove that a new build or installer package is correctly signed.

For an installer package, run the package signature check against the final .pkg, not an intermediate file. Confirm that the signer is the intended Developer ID Installer identity, and run the installation validation your product supports. If an affected old package is already published or queued, identify its distribution locations and replace it with a newly signed package before February 1, 2027. Keep the replacement artifact’s signature and validation evidence with the release record.

Do not collapse the evidence into one “signing passed” checkbox. Record at least the certificate issuer and purpose, CI identity selected, application signature result, package signature result when relevant, notarization status, timestamp or stapling result where relevant, and the artifact version tested. This makes the acceptance decision auditable if a later release uses a different keychain or signing job.

Step 5: Roll out gradually and retain a tested fallback

Once the isolated job passes, update production Mac CI references in a controlled release change. Replace old identity references in build settings, scripts, secrets, and keychain provisioning. Then run a production-like release candidate and verify its artifacts before removing the old path. A fallback is useful only if it is documented and does not accidentally reintroduce an affected certificate into a public release.

Assign ownership for certificate expiry review. Include issuer and purpose in the renewal record, not just the display name or expiration date. Add a reminder to review the G2 certificate against Apple’s current instructions before its own renewal window; do not assume the current replacement procedure will remain unchanged. Recheck Apple’s announcement and certificate guidance before the February 1, 2027 deadline, and update your release plan if Apple changes its documentation.

For a team comparing infrastructure options, a local Mac gives direct hardware and keychain control but requires the team to maintain the host. A remote Mac can provide a separate environment for a short acceptance run, but your team still owns the signing policy, credentials, and release evidence. A Linux-only CI runner cannot run the macOS signing and notarization workflow itself; a manual workstation fallback can leave the tested artifact and production pipeline out of sync.

Frequently asked questions

The answers below cover the checks that commonly delay a certificate rotation. Apply them to the exact certificate and artifact in your release path rather than treating the expiration as a blanket migration.

How do I confirm which Sub-CA issued the certificate in Mac CI?

Inspect the certificate chosen by the CI job and read its Issuer field. A certificate’s name or expiry date is not enough to establish whether it came from the original Developer ID Certification Authority Sub-CA. Compare the Issuer with Apple’s intermediate certificate information, then map that identity to the workflow and artifact it signs. Keep the result in your certificate inventory.

What should I retest after replacing a certificate with G2?

Run the real CI job under its normal execution account. Verify identity availability and keychain access, then test application signing, installer signing if used, notarization submission, final notarization status, and the artifact checks your release requires. Store each result separately. A manually signed local build is useful for diagnosis, but it does not demonstrate that the CI account can access the key or complete the release workflow.

How should I handle a .pkg signed by an affected Installer certificate?

Create a replacement Developer ID Installer certificate through G2 and use it to sign a fresh package. Check the signature on the final .pkg, validate installation using your supported release checks, and replace affected packages in distribution channels before February 1, 2027. Keep an inventory of published and queued packages; do not assume that replacing the application’s Developer ID Application certificate updates an installer package.

Do I need to re-sign an already notarized Mac app?

Apple says an already notarized Mac app with a secure timestamp does not need to be re-signed solely because the original Sub-CA expires. Verify those conditions for the specific distributed app, including the signature and notarization evidence. Do not extend this exception to .pkg files, newly built artifacts, or apps whose timestamp or notarization status you cannot confirm.

Choose the test environment that fits the release risk

If your current approach relies on a Linux-only runner, an engineer’s workstation, or a single shared Mac, the practical costs are different: the Linux runner cannot perform macOS-native signing, workstation tests may use a different account and keychain from CI, and a shared host can make credential changes harder to isolate. For a temporary certificate rotation or controlled release rehearsal, renting a Mac can give you a separate macOS environment without buying another machine. If your team needs permanent, high-volume signing capacity or direct physical-device access, evaluate a dedicated Mac instead; rental is not automatically the right long-term choice.

If a temporary test environment fits your needs, review MACGPU’s Mac options and confirm that the access model meets your security and operational requirements before moving signing credentials. Use it to validate the Mac CI workflow you control, not as a substitute for your team’s certificate custody policy.