Apple Developer ID Sub-CA Expiring: Developers Must Replace Their Certificates

Apple has issued an important notice to the developer community: the legacy Developer ID Certification Authority (Sub-CA) is approaching its expiration date. This change will directly affect the signing validity of macOS applications and installers, and all teams distributing software within the Apple developer ecosystem need to prepare in advance.

Expiration Date and Scope of Impact

According to Apple's official announcement, the original Developer ID Certification Authority (Sub-CA) will expire on February 1, 2027. All certificates issued by this authority will stop working after that date. This means software distribution pipelines that rely on these certificates for signing may experience interruptions.

The most immediate impact for developers lies in their distribution channels. Installer packages (.pkg) signed with affected certificates will no longer be able to execute installations. However, Mac apps that have already been signed, notarized, and include a secure timestamp will continue to work. In other words, this change doesn't uniformly invalidate all legacy software — it treats different distribution formats differently.

How to Determine Whether You're Affected

Apple recommends that developers log in to the Certificates, Identifiers & Profiles section of their account and check whether any certificates expire on or before February 1, 2027. Apple also provides a help document titled "Replacing Developer ID certificates issued from the previous Sub-CA" to help identify which certification authority issued a given certificate.

This step is critical, because looking at the expiration date alone isn't enough to determine a certificate's origin. You need to confirm that a certificate was actually issued by the legacy Sub-CA before proceeding with a replacement. For large teams managing multiple certificates, checking each one individually helps avoid oversights or mistakes.

The Correct Approach to Creating New Certificates

The solution is to regenerate replacement certificates from the current issuing authority: Developer ID Certification Authority (G2). Note that the G2 certification authority itself remains valid until 2031, but the individual certificates it issues still expire annually and must be renewed each year — consistent with how things have always worked.

Two details are easy to overlook during the generation process:

• If you're still using Xcode 11.4 or earlier, you must upgrade before creating new certificates; otherwise you may not be able to use the new authority correctly.
• When prompted to select a Developer ID Certificate Intermediary, be sure to choose G2 Sub-CA. Selecting the wrong option could result in a certificate that also expires in 2027, making the entire migration pointless.

This serves as a reminder that replacing a certificate isn't as simple as clicking "generate" again — choosing the wrong intermediate authority will undo all your migration work.

---

Certificate Chain is the foundational concept for understanding this change. A Developer ID certificate doesn't exist in isolation — it forms a chain of trust composed of a Root CA → Intermediate CA (Sub-CA) → Developer end-entity certificate. The operating system verifies software trustworthiness by validating each link in this chain. When any node in the chain — including the intermediate certification authority — expires or becomes invalid, the entire chain's verification fails. This is the root cause of the current situation: once the legacy Sub-CA expires, all developer certificates issued beneath it will fail verification even if they haven't individually expired, because they lack a valid endorsement from the layer above. G2 is Apple's next-generation intermediate certification authority introduced to replace the legacy Sub-CA, with a validity period extending to 2031. Developer certificates re-issued from G2 will be built on a complete and valid chain of trust.

---

Re-signing Based on Distribution Method

After creating new certificates, you'll need to take different actions depending on what you're distributing.

Installer Packages (.pkg): Starting February 1, 2027, .pkg files signed with affected certificates will fail to install. Developers must re-sign all installer packages with new certificates before that date. This is the part of the change with the clearest time pressure.

Mac Apps: Previously signed and notarized Mac software that includes a secure timestamp will continue to work normally with no additional action required. For future updates, sign with the new certificate and include a secure timestamp during notarization.

Secure timestamps play a key role here — they're what allows already-notarized software to remain valid even after the original signing certificate expires. This is an important guarantee built into Apple's notarization system.

---

Secure Timestamp is a cryptographic proof embedded during the code signing process by a trusted Timestamping Authority (TSA), recording the precise time the signing action occurred. Apple's notarization process solidifies this timestamp alongside the signature in the software package. The core value is this: even if the certificate used for signing later expires or is revoked, verifiers can still prove that "the signing occurred when the certificate was valid," allowing the software to continue running. This mechanism is why already-notarized Mac apps are unaffected by the Sub-CA expiration — as long as a secure timestamp was correctly embedded during notarization, the certificate's subsequent status cannot retroactively affect the trustworthiness of already-distributed software. The reason .pkg installers face stricter requirements is that the installer validates the certificate chain's current validity at the time of execution, rather than relying on a historical timestamp.

---

Action Checklist for Developers

Overall, this certificate migration isn't particularly complex in terms of process, but it involves date-sensitive deadlines and a few easy-to-miss details. Development teams are advised to audit their certificates early rather than scrambling close to February 2027 — especially for products distributed via .pkg, which need re-signing completed ahead of time. For Mac apps distributed through notarization, the impact is more manageable, but new releases should still switch to G2 certificates and maintain secure timestamps.

Certificate management is the kind of foundational infrastructure that's easy to overlook but can have far-reaching consequences. Auditing certificate origins, updating development tools, and standardizing the signing process ahead of time are all essential to ensuring software distribution isn't disrupted by certificate expiration.