Lost or revoked iOS distribution certificate: what to do
· 7 min read
Sooner or later every iOS team hits this: the Mac that created the distribution certificate is wiped, the developer who set up signing has left, or someone revoked a certificate to make room for a new one. Suddenly Xcode says the signing identity is missing its private key, or CI fails with a "no signing certificate found" error, and nobody is sure what still works.
The good news is that this is recoverable. The bad news is that the impact depends on how your apps were distributed, and getting that wrong is how a small signing problem turns into broken apps on users' phones. This guide covers what breaks, what does not, how to recover, and how to keep it from happening again.
Lost and revoked are two different problems
A distribution certificate has two halves. Apple holds the certificate, which you can download again from your developer account at any time. The private key was created on the Mac that made the certificate signing request, and Apple never has a copy. Without the private key, the downloaded .cer file cannot sign anything.
- Lost: the private key is gone (wiped Mac, no backup), but the certificate is still valid in Apple's system. Nothing that was already signed is affected. You just cannot sign anything new with it.
- Revoked: the certificate is no longer valid, whoever has the key. Apple documents that provisioning profiles containing a revoked certificate become invalid, and that has consequences for builds already out there.
This difference matters, because the instinct when a key is lost is to revoke the certificate. Often you do not need to. Apple's own engineers describe revocation as a measure for a compromised key, not a lost one.
What breaks and what does not
| Distribution | Key lost, certificate still valid | Certificate revoked |
|---|---|---|
| App Store apps already live | Keep working | Keep working while your membership is valid |
| Builds uploaded, not yet submitted for review | Not affected | May be marked Invalid Binary; upload again |
| Ad Hoc builds on testers' phones | Keep working until the profile expires | Profile becomes invalid; plan to reinstall a newly signed build |
| Enterprise (in house) apps | Keep working until the certificate expires | Users can no longer run them |
| New builds of any kind | Cannot be signed until you have a new certificate | Cannot be signed until you have a new certificate |
The Enterprise row is the dangerous one. Apple states plainly that when an in house distribution certificate expires or is revoked, users can no longer run apps signed with it, and you must ship a new version signed with a new certificate. For a company with an internal app on hundreds of devices, revoking that certificate by mistake takes the app away from everyone at once.
App Store apps are the safest: Apple re-signs what it delivers to users, so revoking your distribution certificate does not touch apps that are already live.
Ad Hoc builds sit in between. They depend on the profile, and a profile that references a revoked certificate is no longer valid. Treat every Ad Hoc build signed with a revoked certificate as one that testers will need to replace.
Recovery, step by step
1. Look for a backup first
Before creating anything new, check whether the private key still exists somewhere:
- Another Mac on the team: in Keychain Access, under My Certificates, look for
Apple Distribution: Your Team (TEAMID)with a disclosure arrow. The arrow means the private key is there. - A
.p12file in your password manager, secrets vault or CI secret store. Many teams exported one for CI and forgot about it. - A signing repository used by Fastlane match or a similar tool, which stores certificates and keys encrypted.
If you find it, import the .p12 on the new Mac and you are done. Nothing needs to be revoked.
2. Create a new distribution certificate
If the key is truly gone, create a new certificate. Only the Account Holder or an Admin can create distribution certificates.
- In Xcode: Settings, Accounts, select the team, Manage Certificates, then add an Apple Distribution certificate. Xcode creates the key on this Mac.
- In the portal: create a certificate signing request with Keychain Access (Certificate Assistant, Request a Certificate From a Certificate Authority), upload it under Certificates, then download and install the certificate.
Apple limits how many distribution certificates a team can hold. If you are at the limit, the portal or your CI tool will refuse a new one, often with an error saying you already have a current distribution certificate or have reached the maximum number of certificates. Only then do you need to revoke one, and before you do, check the table above against what that certificate signed. If it is an Enterprise certificate, have the replacement build ready and distributed first.
3. Regenerate the provisioning profiles
Profiles name the certificates that may sign with them. For each Ad Hoc, Enterprise or App Store profile, edit it in the portal, select the new certificate, save and download. Automatic signing in Xcode does this for its managed profiles. In CI, refresh the stored profiles, otherwise the pipeline keeps using copies that point to the old certificate.
4. Rebuild, verify and redistribute
Export the build again with the new profile. Before sending it out, drop the .ipa into the IPA inspector: it reads the file in your browser and shows the certificate name, the profile, its expiry and the provisioned devices, so you can confirm the new identity is the one in the build. Then share the new build with testers. If the old certificate was revoked, tell testers explicitly that they need to install the new build; old installs will not update themselves. If the old profile also had stale devices, this is a good time to clean up the list, as described in register devices for Ad Hoc builds.
Errors you will see along the way
- "Missing private key" next to the certificate in Xcode's Manage Certificates: the certificate exists in your account but the key is not on this Mac. Import the
.p12or create a new certificate. - "No signing certificate iOS Distribution found" or similar in xcodebuild: the keychain on the build machine does not have a usable identity. Check that the
.p12was imported into the keychain CI actually uses, and that it includes the key. - Testers get "Unable to Install" or an installed app stops opening: often the profile no longer matches a valid certificate. More cases are in iOS code signing errors that block test installs.
Team practices that prevent this
- Export a .p12 the day you create a certificate. In Keychain Access, select the certificate together with its key, Export, choose a strong password, and store the file and password in a shared vault. Do not email it and do not commit it to a repository.
- Keep one owner and one written procedure. Decide who creates and revokes distribution certificates, and write down where the backup lives. Most "lost" keys are really keys that one person had.
- Never revoke as a reflex. Revoke only when a key is compromised, or when you are at the certificate limit and you have checked what the certificate signed.
- Use a signing store for CI. Fastlane match, your CI provider's encrypted secrets, or Xcode's cloud managed certificates (which keep the key with Apple instead of on one machine) all mean the key no longer lives on one person's laptop.
- Track expiry dates. Certificates and profiles expire about a year after creation. Put the dates in the team calendar and create replacements a few weeks early. Enterprise teams can keep two distribution certificates so the new one is in place before the old one ends.
- Use App Store Connect API keys with the least role needed. A key with an Admin role can create and revoke certificates. Give CI and third party tools only what they need.
Where AppForShare fits
AppForShare does not hold or manage signing identities, and it does not re-sign builds: it shares the file you export, as an install link and QR code. What it can do is help you notice signing problems early. Every build uploaded to an account gets a store readiness check that includes profile expiry, and the "what changed" view compares each build with the previous one of the same app, including provisioned devices. The free IPA inspector needs no account at all. When your new certificate is in place, create a free account and share the rebuilt build with your testers, or see the pricing page for links that stay live while you are subscribed.
