IPAFlowEarly Access

IPAFlow / errors / distribution certificate expired

Installation errors

Fix an Expired iOS Distribution Certificate

Identify which Apple signing certificate expired, determine the distribution-specific impact, then create and verify only the replacement assets the release actually needs.

Updated August 22, 2026

First prove which certificate expired and which distribution workflow depends on it. “Distribution certificate expired” is not one universal failure mode, and the effect on an App Store app is not the same as the effect on an internal or locally signed build.

Keep these states separate:

certificate expiration
certificate revocation
provisioning-profile expiration
Apple Developer membership state
TestFlight build availability
existing store installation

Changing one does not automatically change the others.

Identify the exact certificate and identity

On the build Mac:

security find-identity -v -p codesigning
security find-certificate -a -c "Apple Distribution" -Z
security find-certificate -a -c "Apple Development" -Z

Record the certificate type, team, serial/fingerprint, expiration date, and whether a usable identity still appears. A public .cer file is not enough to sign; the matching private key must be available to the signing process unless the workflow uses Apple-managed cloud signing.

Apple’s TN3161 explains that the private key is created as part of the CSR/Xcode certificate process and is what turns the issued certificate into a code-signing identity.

Know which certificate family you are looking at

For modern Xcode workflows:

Do not apply a Developer ID rule to an iOS client build merely because both involve certificates.

App Store impact is explicitly different

Apple’s current certificate overview states that when Apple Developer Program membership remains valid, existing apps on the App Store are not affected by expiration of an iOS Distribution certificate. The expired certificate cannot be used to sign and upload new apps or updates to App Store Connect.

Apple also notes that builds already uploaded but not yet submitted may have additional consequences when the signing certificate is revoked. Expiration and revocation are not interchangeable states.

Therefore, an expired local distribution certificate does not mean users must reinstall an existing App Store app.

Development and Ad Hoc: diagnose the exact artifact

Development and Ad Hoc releases rely on an app’s signing identity plus provisioning authorization. An expired certificate blocks reuse of that identity for new signing work. Profiles that authorize an obsolete identity may need regeneration before the next build or authorized re-sign.

Do not copy the App Store “existing app unaffected” rule onto a Development or Ad Hoc artifact without evidence. For a failing registered-device build, inspect:

If a replacement is required, create a current identity, regenerate the affected profile, produce a new signed artifact, and verify that artifact. Do not tell a tester to change phone settings to compensate for expired signing assets.

Proprietary in-house distribution is stricter

Apple’s current certificate overview explicitly says that users can no longer run internal-use iOS apps signed with an expired or revoked iOS Distribution certificate, and the organization must distribute a new version signed with a new certificate.

This is an Enterprise/internal-use rule. Do not use Enterprise distribution as a shortcut for ordinary client testing.

Developer ID is a separate macOS case

Apple documents different Developer ID behavior: a Mac app signed while the Developer ID Application certificate was valid can generally continue to download, install, and run after that certificate expires, while certificate revocation has different consequences. Developer ID provisioning-profile expiration is also a separate launch condition.

That distinction is exactly why “all signing certificates behave the same after expiry” is unsafe guidance.

Profile expiry is a different fault

Decode the profile in the exact artifact:

security cms -D \
  -i "$APP_PATH/embedded.mobileprovision" \
  -o /tmp/profile.plist

plutil -extract ExpirationDate raw -o - /tmp/profile.plist
plutil -extract DeveloperCertificates xml1 \
  -o /tmp/profile-certificates.plist \
  /tmp/profile.plist

A current certificate does not revive an expired profile. A current profile also does not prove the build machine has the matching private key. If ExpirationDate itself is past, use Expired Provisioning Profile.

Recover with the minimum signing changes

Once the affected workflow is proven:

  1. create or obtain a valid replacement certificate through the authorized Apple/Xcode workflow;
  2. confirm the corresponding private key or cloud-managed signing path exists;
  3. identify active profiles that authorized the old certificate;
  4. regenerate only the profiles the active releases require;
  5. preserve the intended App ID, entitlements, distribution type, and device set;
  6. rebuild from source or perform an authorized re-sign;
  7. inspect the replacement IPA’s signature and embedded profile;
  8. checksum the replacement;
  9. replace the delivery object; and
  10. acceptance-test that exact artifact.

Apple’s current profile help says invalid or expired profiles need regeneration. A similarly named profile in Downloads is not proof that the final IPA used it.

Cloud-managed distribution changes where the key lives

Apple documents cloud-managed distribution certificates for modern Xcode distribution workflows. In supported Organizer workflows, Xcode can cloud sign when a local signing certificate is not found, and Apple manages the private key remotely.

Do not treat that as evidence that every CI or manual re-sign workflow can sign without a local identity. Cloud-managed signing is a specific Apple-supported path; a custom codesign or Fastlane workflow still needs the credentials required by that workflow.

These actions do not rewrite an old IPA

None of the following modifies the signed contents of an already exported IPA:

A replacement release needs a new valid signing operation and then independent verification.

Prevent expiry from becoming a delivery incident

Track signing lifecycle per active release pipeline:

Do not revoke working certificates simply because one certificate is near expiry. Apple also supports cloud-managed certificate rotation in eligible workflows; use the signing model the project already owns instead of mixing multiple systems during an incident.

After recovery, verify with Check an IPA’s Code Signature and run the iOS Distribution Checklist before re-delivery. The outcome should be a traceable new artifact, not merely a newer certificate in the developer account.

Related next steps

Next step. Prove the certificate type and affected workflow first, then create a replacement identity and verify the exact new artifact before re-delivery. Join Early Access.

Sources