A provisioning profile is not a pointer to your team's certificates. It is a signed plist that embeds copies of the specific certificates allowed to sign with it, captured at the moment Apple generated the file. Nothing about that list updates later. Issue a new certificate today and every profile created yesterday still authorizes only yesterday's certificates.
So this error is almost never a mystery once you know the rule. Something changed on the certificate side after the profile was made. The fix is nearly always to regenerate the profile, and the interesting question is which of the four usual things happened.
What changed
- The certificate was rotated
- Somebody renewed an expiring distribution certificate. The new one is valid, it is in your keychain, and no existing profile references it. This is the single most common cause, and it tends to hit a whole team at once.
- A teammate revoked and recreated it
- Usually a fastlane match nuke, or a cleanup in the Apple Developer portal. Your local keychain may still hold the old certificate too, which makes the situation more confusing than it needs to be.
- You are signing with the wrong identity
- Two certificates of the same type exist on the team, your Mac has one, and the profile was built against the other. Common when several developers each generated their own distribution certificate.
- The profile came from somewhere stale
- A .mobileprovision checked into the repo months ago, or a cached copy in Xcode's profiles directory that predates the certificate change. The portal has a correct profile; your machine is not using it.
Confirm which certificate the profile expects
Before regenerating anything, it is worth ten seconds to see inside the profile. The DeveloperCertificates array holds the authorized certificates as raw DER blobs, and you can read the first one straight out with openssl.
# Decode the profile into a readable plist security cms -D -i MyApp_App_Store.mobileprovision > /tmp/profile.plist # What the profile covers /usr/libexec/PlistBuddy -c 'Print :Entitlements:application-identifier' /tmp/profile.plist /usr/libexec/PlistBuddy -c 'Print :ExpirationDate' /tmp/profile.plist # The certificate it authorizes /usr/libexec/PlistBuddy -c 'Print :DeveloperCertificates:0' /tmp/profile.plist \ | openssl x509 -inform DER -noout -subject -dates -fingerprint
# The certificates you can actually sign with security find-identity -v -p codesigning
Compare the fingerprint or the subject line from the profile against that list. If they differ, the diagnosis is confirmed and there is nothing left to investigate.
Regenerating the profile
- 1
Edit the profile in the Apple Developer portal
Certificates, Identifiers and Profiles, Profiles, select it, Edit. Tick the current certificate in the list, save, and download the regenerated file. Apple issues a new file rather than updating the old one in place.
- 2
Delete the stale copy from your machine
Xcode will happily keep using a cached profile with the same name. Remove the old .mobileprovision from the profiles directory before installing the new one, or you will fix this twice.
- 3
Install the new profile and rebuild
Double-click the downloaded file, or copy it into the profiles directory. Then clean the build folder, because the previous signing decision is cached in derived data.
- 4
Do the same for every other profile on the team
If a certificate rotated, it did not only break this one profile. Ad Hoc, Development, and any extension profiles referencing the same certificate all need the same treatment.
# Xcode 16 and later PROFILES=~/Library/Developer/Xcode/UserData/Provisioning\ Profiles # Xcode 15 and earlier # PROFILES=~/Library/MobileDevice/Provisioning\ Profiles rm "$PROFILES"/*.mobileprovision cp ~/Downloads/MyApp_App_Store.mobileprovision "$PROFILES/"
With automatic signing
If you are using automatic signing, Xcode is supposed to handle this for you, and usually does. When it does not, toggling Automatically manage signing off and on forces a re-resolve. From the command line the equivalent is -allowProvisioningUpdates, which lets xcodebuild create and repair profiles mid-build.
xcodebuild archive \ -scheme MyApp \ -archivePath build/MyApp.xcarchive \ -allowProvisioningUpdates \ -authenticationKeyPath /path/to/AuthKey_ABC123.p8 \ -authenticationKeyID ABC123 \ -authenticationKeyIssuerID 00000000-0000-0000-0000-000000000000
With fastlane match, the same problem shows up when the repo holds a profile generated against a certificate that has since been replaced. A readonly run will not fix it, because readonly refuses to regenerate anything. You need one read-write run by someone with the right portal permissions, then push the updated repo.