IPAFlowEarly Access

IPAFlow / errors / profile certificate mismatch

Installation errors

Fix a Provisioning Profile and Signing Certificate Mismatch

Prove whether the certificate that signed an iOS app is authorized by its embedded provisioning profile, then repair only the mismatched signing inputs.

Updated August 22, 2026

A certificate/profile mismatch means the certificate that signed—or is about to sign—the app is not one of the certificates authorized by the provisioning profile for that target. Do not repair it by guessing from profile names or by revoking every certificate.

Keep four objects separate:

certificate
+ matching private key
+ provisioning profile
+ signed app artifact

A certificate installed on a Mac is not automatically a usable signing identity. Apple defines an identity as a certificate paired with its corresponding private key. A valid certificate from the same team is also not automatically authorized by a specific profile.

What each piece of evidence proves

These are four separate facts.

certificate present
  != private key present
  != profile authorizes certificate
  != final IPA used that identity

Apple’s TN3125 describes DeveloperCertificates as the profile’s answer to “who is allowed to sign code?” Apple also warns that the readable provisioning-profile property list is diagnostic material, not a stable product API; modern systems use the DER-encoded profile as the source of truth.

Preserve the failing artifact first

Work from the exact IPA that failed or was delivered:

shasum -a 256 ClientBuild.ipa
mkdir ClientBuild-unpacked
unzip -q ClientBuild.ipa -d ClientBuild-unpacked
APP_PATH=$(find ClientBuild-unpacked/Payload -maxdepth 1 -name '*.app' -print -quit)

Record filename, checksum, version/build, intended Apple Developer team, and distribution method. Do not edit the extracted app while diagnosing it.

Step 1: identify who actually signed the app

codesign --display --verbose=4 "$APP_PATH" 2>&1
codesign --verify --strict --verbose=4 "$APP_PATH"

Record the signing authority, TeamIdentifier, code-signing identifier, and verification result. A successful local verification proves the inspected signature is internally valid under the requested check; it does not prove the embedded profile authorizes that identity.

For the canonical signature-evidence workflow, use Check an IPA’s Code Signature.

Step 2: decode the embedded profile

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

plutil -extract Name raw -o - /tmp/client-profile.plist
plutil -extract UUID raw -o - /tmp/client-profile.plist
plutil -extract ExpirationDate raw -o - /tmp/client-profile.plist
plutil -extract Entitlements.application-identifier raw -o - /tmp/client-profile.plist
plutil -extract DeveloperCertificates xml1 \
  -o /tmp/profile-certificates.plist \
  /tmp/client-profile.plist

Do not conclude from the profile name. Compare the actual app identity, team context, profile application identifier, certificate authorization, expiry, entitlements, and device set where applicable.

Step 3: compare exact certificate identities

TN3125 shows that the certificate records in DeveloperCertificates can be extracted and inspected. Use serial numbers and fingerprints rather than display names alone.

For example, after extracting one certificate record to a .cer file, compare its SHA-256 fingerprint with the signing certificate you expect. The goal is a positive identity match, not “both say Apple Distribution.”

A common failure is:

new Apple Distribution certificate created
→ old provisioning profile still authorizes previous certificate
→ build machine uses new identity
→ profile and signature disagree

Another is the opposite:

profile authorizes current certificate
→ build machine has only public .cer
→ matching private key is missing
→ no usable signing identity exists

Step 4: verify the private key on the signing machine

List usable code-signing identities and installed certificates separately:

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

If a certificate appears in find-certificate but not as a usable identity, investigate the matching private key and Keychain access. Downloading the .cer again does not recreate a private key that was generated on another machine.

Apple’s certificate technote explains that the CSR process creates the key pair first; importing the issued certificate later completes the identity only when the matching private key is present.

Step 5: rule out neighboring failures

A certificate/profile mismatch is not the same as:

Do not replace several assets at once before you know which branch is true.

Common real causes

Inspect nested targets explicitly

Extensions, widgets, App Clips, and nested apps can have their own bundle identifiers, profiles, and signing requirements. Enumerate them:

find "$APP_PATH" -type d \
  \( -name '*.appex' -o -name '*.app' \) -print

Inspect each signed target rather than assuming the main app proves the whole IPA. A correct outer signature does not repair a nested certificate/profile mismatch.

Choose the minimum repair

Use the smallest repair supported by the evidence:

  1. Use an already-authorized certificate and its matching private key when that is the intended signing identity.
  2. Regenerate or edit the intended profile to authorize the correct current certificate when the profile is stale.
  3. Return to Xcode-managed signing when automatic signing owns the project instead of building a parallel manual profile set.
  4. Perform an authorized re-sign only when the app owner controls compatible signing assets and every target can be mapped correctly.

For an Ad Hoc profile, Apple’s current workflow selects one distribution certificate, the matching App ID, and registered devices. For a Development profile, the workflow can select one or more development certificates and devices. Use the profile type that matches the actual distribution method.

Fastlane’s resign can apply a signing identity and provisioning profile mappings to an existing IPA, but automation cannot make incompatible assets compatible. How to Re-sign an IPA Safely owns that boundary.

Verify the replacement, not just the portal

After the repair:

  1. checksum the replacement IPA;
  2. verify the main app and nested signatures;
  3. decode every applicable embedded profile;
  4. confirm profile UUID/expiry/team/App ID;
  5. confirm the signing certificate is authorized by DeveloperCertificates;
  6. confirm device membership where the distribution method requires it; and
  7. acceptance-test the exact delivered checksum.

Run the iOS Distribution Checklist before replacing the client link. The goal is not “a new certificate exists”; the goal is one verifiable artifact whose signature, profile, app identity, device authorization, and delivery record agree.

Related next steps

Next step. Preserve the original IPA, prove the certificate/profile mismatch, then replace only the signing input that is wrong. Join Early Access.

Sources