IPAFlow / errors / no signing certificate found

Installation errors

Fix “No Signing Certificate Found” in Xcode or CI

Diagnose whether the build environment is missing a certificate, private key, Keychain access, correct team, compatible profile, or synchronized signing assets.

Updated August 22, 2026

“No signing certificate found” usually means the current build environment cannot assemble a usable code-signing identity for the selected target and signing configuration. A .cer file by itself is not a signing identity.

For normal local signing, think in this chain:

certificate
+ matching private key
+ usable Keychain access
+ correct certificate type/team
+ compatible provisioning/signing configuration
= usable local signing identity

Apple defines an identity as a certificate paired with its associated private key. If either side is missing, the identity does not exist from the signing process’s point of view.

Start with the exact error and machine

Record:

the full Xcode or CI error;
target and configuration;
selected Apple Developer team;
automatic vs manual signing;
certificate type expected;
profile/export method; and
the exact build machine or runner.

Do not revoke or create certificates until you know which state is missing.

Decision tree

A. Certificate is not installed

Run:

security find-certificate -a -c "Apple Distribution" -Z
security find-certificate -a -c "Apple Development" -Z

If the expected certificate is absent from the relevant Keychains, install or synchronize the approved identity through the project’s established signing workflow.

B. Certificate is installed but the private key is missing

Run:

security find-identity -v -p codesigning

If the certificate appears in find-certificate but no corresponding usable identity appears in find-identity, investigate the private key first.

Apple’s TN3161 explains the common trap: the private key is created on the Mac during the CSR/Xcode certificate process. Downloading the public certificate on another Mac does not recreate that key.

C. Private key exists but is inaccessible

The identity may exist in a Keychain that the build step cannot access, a locked Keychain, or a Keychain outside the process search list. This is common in CI and remote build environments.

Diagnose Keychain visibility and access deliberately. Do not copy private keys into the repository or print secrets into CI logs.

D. Certificate expired

Check validity and compare it with the intended release. If expired, use Expired iOS Distribution Certificate rather than repeatedly importing the same certificate.

E. Certificate was revoked

Revocation is different from expiration. Preserve the exact account state, identify profiles and releases that depended on that certificate, and create a controlled replacement. Do not assume an expired-certificate repair description covers revocation consequences.

F. Wrong certificate type

A valid Apple Development identity is not a substitute for an Apple Distribution identity when the export requires distribution signing. Confirm what the target and distribution method require rather than choosing the first identity Xcode lists.

G. Wrong Apple Developer team

A usable identity from Team A does not sign an App ID/profile owned by Team B. Confirm the project target, archive/export team, and profile all point to the same intended organization.

H. Profile does not authorize the certificate

A usable identity can exist locally while the selected profile’s DeveloperCertificates set authorizes another certificate. That is Profile and Signing Certificate Mismatch, not a missing-certificate problem.

I. Keychain search-list or lock problem

In CI, a temporary Keychain may contain the identity but never be unlocked or added to the build process’s search path. Capture the runner’s Keychain state without leaking passwords or exported identity material.

J. CI import or secret problem

A PKCS#12 import can fail because the artifact is wrong, the password is wrong, the secret is truncated, or the imported item is not the expected team/certificate. Validate the imported identity after import; do not infer success from a zero-error setup step alone.

K. Automatic/manual signing conflict

If Xcode owns signing automatically, introducing a parallel manual profile and identity mapping can create ambiguity. If the project intentionally uses manual signing, make the team, certificate, App ID, and profile mapping explicit.

L. WWDR intermediate-chain issue

Apple’s current WWDR documentation identifies the G3 intermediate as the software-signing chain for Apple Development, Apple Distribution, legacy iOS Development/Distribution, and related certificates. Eligible Xcode versions install supported intermediates automatically.

Check the intermediate chain only when trust or certificate-chain evidence points there. Do not install random certificate files from third-party sites.

M. Fastlane/match synchronization problem

Fastlane’s current match action is an alias for sync_code_signing. It synchronizes certificates, private keys, and provisioning profiles from the team’s configured signing store and supports multiple targets and teams.

If the signing store never contained the matching private key, match cannot reconstruct it from the public certificate alone. If the store does contain the approved identity, synchronize it before the build and verify what arrived in the Keychain.

Verify the identity locally

Use both certificate and identity views:

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

Interpretation:

certificate visible + identity missing
  → private key or Keychain-access problem likely

identity visible + Xcode still fails
  → inspect team, certificate type, profile, target, signing mode, and export mapping

A certificate common name is not enough. Compare team, fingerprint/serial, type, validity, and profile authorization.

Inspect the profile when manual signing is involved

security cms -D -i ClientApp.mobileprovision \
  -o /tmp/client-profile.plist

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

The profile must authorize the certificate the build intends to use. A similarly named profile from another app or team can produce the same surface-level Xcode complaint.

CI: keep the fix reproducible and secret-backed

A safe CI workflow should:

use an approved secret source for the signing identity;
create or select the intended Keychain deliberately;
unlock it only for the required build context;
make it visible to the signing process;
import the identity without printing the password or private key;
synchronize the intended profiles;
verify security find-identity after setup; and
clean up ephemeral Keychain material according to the runner model.

Do not email P12 files, commit them to the app repository, paste them into issue trackers, or generate a new distribution certificate on every CI run.

Cloud-managed certificates are a separate supported path

Apple documents that supported Xcode Organizer distribution workflows can use cloud-managed distribution certificates when a local distribution certificate is not found. In that model Apple manages the certificate/private key remotely.

Do not assume this applies to arbitrary command-line, CI, or re-sign workflows. Diagnose the signing model the project actually uses.

Fastlane match: what it can and cannot do

Current match documentation says it stores and synchronizes certificates with their private keys plus provisioning profiles, and can repair broken or expired credentials within its managed workflow.

It can help when the signing store is the source of truth. It cannot magically recover a private key that was never stored, resolve the wrong Apple team, or make an incompatible profile authorize the wrong certificate.

For Ad Hoc signing-store design, use Fastlane Match for Ad Hoc.

Rebuild, then inspect the final IPA

Getting Xcode past the signing error is not the final acceptance condition.

After the build succeeds:

checksum the exported IPA;
inspect the actual signing identity;
verify the code signature;
decode the embedded profile;
confirm team/App ID/certificate authorization;
check nested targets; and
acceptance-test the exact artifact.

Use Check an IPA’s Code Signature and the iOS Distribution Checklist before client delivery. The goal is not merely “Xcode found a certificate”; it is a reproducible signing environment that produced the intended verified artifact.

Related next steps

Next step. Prove which identity component is missing before creating, revoking, or importing any signing asset. Join Early Access.