iOS Distribution Certificate: Expired or Lost

An iOS distribution certificate is the signing identity that tells Apple a build really came from your team, and without a valid one you can’t upload a new build to App Store Connect. Apple calls the current type Apple Distribution, and it belongs to the team rather than to one person. When it expires or gets revoked, apps already on the App Store keep working, but the next update you try to ship is refused until you replace the certificate and rebuild.

The pages that rank for this term are mostly one-time answers. There’s an old Stack Overflow thread on the difference between development and distribution certificates, a few step-by-step tutorials for creating one in Xcode, and a handful of renewal guides. They work fine when you’re the developer who created the certificate yesterday, and they say very little about the situation that actually causes release-day trouble: the certificate was created years ago by someone who left, the private key lived on one laptop, and nobody knows which role on the Apple account can fix it. This article covers the rules Apple documents, then what to check when you’ve inherited the app.

What does an iOS distribution certificate actually do?

It lets you sign a build so that Apple, and later the device, can verify who produced it. Apple’s certificate overview lists Apple Distribution next to Apple Development, and it says development certificates belong to individual team members while distribution certificates belong to the team. That split matters because a developer can leave and take their development certificate with them, but the distribution certificate should outlive any single person.

Signing needs two things that people often mix up. The certificate is the public half, which you download from the Apple Developer portal, and the private key is the half that was generated on the machine that made the certificate signing request. A certificate without its private key looks fine in the portal and is useless for signing, so the usual “it’s in the portal, so we’re fine” check proves nothing.

Provisioning profiles tie the certificate to an app identifier and, for ad hoc and development builds, to a list of devices. For an App Store build the profile is the third piece, and it’s the one that quietly goes invalid when the certificate behind it changes. The old iOS Distribution name still shows up in many projects and tutorials, and Apple says it applies to Xcode 11 and earlier, so seeing it on an old project just tells you how long ago the certificate was made.

What happens to your app when the certificate expires?

Nothing visible happens to customers, which is the reason the problem tends to be discovered late. Apple states that apps already on the App Store aren’t affected by an expired or revoked distribution certificate, provided your Apple Developer Program membership is valid. People who already installed the app keep using it, and new people can still download it.

What changes is your ability to ship. Apple says you can no longer upload new apps or updates signed with the expired or revoked certificate to App Store Connect, so the first sign is usually an Xcode archive or an upload that fails when you try to release a fix. If the failing release is a crash fix or a deadline-driven update, that discovery lands at the worst possible moment.

Apple adds one more consequence worth knowing about. Builds that are already in App Store Connect but haven’t been submitted for App Review can be marked Invalid Binary if they were signed with a revoked certificate. So revocation, unlike plain expiry, can reach back and spoil builds you thought were safely uploaded.

Enterprise and ad hoc distribution behave differently from the App Store path, and one renewal guide I read says enterprise and ad hoc apps stop working on devices when their certificate lapses. That’s relevant only if your app is distributed outside the store, but on an inherited project it’s worth checking whether anyone ever used ad hoc builds for testers, because those are the ones that fail first.

How is expiring different from being revoked?

Expiry is the clock running out, and revocation is somebody pulling the certificate on purpose or by accident. Both stop you from signing new builds with that certificate, but the second one also invalidates things that were already built.

Apple’s revoke-a-certificate page states that provisioning profiles containing a revoked certificate become invalid. That is the part that surprises teams, because revoking one certificate silently breaks every profile that referenced it, and the repair is to edit each profile so it points at a valid certificate and download it again. The same page says the required role is Account Holder or Admin, and it adds that what you can revoke depends on the certificate type and your role.

Revocation is sometimes the right move. If the private key was on a laptop that was lost, or if a former contractor still holds a copy, revoking the certificate closes that door. If you’re only dealing with an expired certificate, you don’t need to revoke anything, and doing it anyway invalidates profiles for no benefit.

One more reason to revoke is the team limit. Apple says only one of each distribution certificate type is allowed per team, with the exception of Developer ID certificates, and the page gives no larger number. If someone left a distribution certificate behind and you can’t create a new one, the old one has to go first, so read the certificate list carefully before you assume you can simply add another.

Who can create a distribution certificate, and why does the Apple account matter?

Only the Account Holder or an Admin can create one, which makes the roles on the Apple Developer account the real bottleneck. Apple’s overview states this directly, and if you enrolled as an individual, you are the Account Holder. A senior engineer with the App Manager role or a developer role can build and test the app, but they can’t create or fix a distribution certificate.

On an inherited app this turns into a short list of questions that you should answer before the first release. Who is the Account Holder, and can they still sign in with the email and the two-factor device on file. Which Admins exist, and are any of them former staff. If the Account Holder was an agency or a founder who moved on, nothing about the certificate can be repaired until that is sorted out.

The same account question underlies a transfer. If the app is moving between Apple Developer accounts, certificates don’t move with it, and our notes on Apple app transfer explain what breaks afterward. Organisation accounts also depend on a verified legal entity, and the Apple Developer DUNS number article covers what slows that down.

Before anyone creates a replacement certificate, ask whether you should. A second certificate made on a developer’s laptop adds another private key to track, and if the team limit applies it could force a revoke you didn’t plan. The cleaner path on a rescued app is usually to decide where signing will live and create the certificate there.

How do you create a new certificate when the old one is gone?

You make a new certificate signing request, upload it in the portal, download the certificate and install it where you sign. Apple’s instructions for the request are to open Keychain Access, choose Certificate Assistant, then Request a Certificate from a Certificate Authority, enter your email and a common name, leave the CA email empty, and select Saved to disk. The request file that comes out is what you upload when you create an Apple Distribution certificate under Certificates, Identifiers & Profiles.

Apple’s page doesn’t say where the private key ends up when you use Keychain Access, and it doesn’t cover losing it. What it does show is that the key is created alongside the request, so the machine that made the request is the machine that holds the key. If that machine is wiped, the certificate you downloaded can no longer sign anything, and the only recovery is another certificate from another request.

This is why a backup of the signing identity is not optional. In Keychain Access you can export the certificate together with its private key as a password-protected .p12 file, and that file is what you store in your team’s secret manager so CI can import it. A renewal guide I read recommends the same backup, and it’s cheap insurance against the next laptop failure.

After the new certificate is installed, regenerate or edit your provisioning profiles so they reference it, download them, and archive again. If you use automatic signing, Xcode can create the certificate and profiles for you, but it needs a role on the account that allows it, which brings you back to the Account Holder and Admin question.

What are cloud-managed certificates, and do they solve this?

They remove the lost-key problem for the people who sign with them. Apple’s help describes cloud-managed certificates as tied to your Apple Developer Program membership and managed remotely. According to Apple, Xcode 13 or later will cloud sign apps for distribution when you use the Organizer archive and distribution workflow and no local signing certificate is found.

Two details from Apple’s documentation are useful for planning. A new cloud-managed certificate is created automatically 90 days before expiry when new signing requests arrive, and Account Holders and Admins can start a manual rotation when signed software has to keep running on devices for longer than 90 days. Those certificates carry a Managed suffix in the portal, and an Apple engineer has said on the developer forums that there’s no way for a developer to renew them by hand.

The trade-off here is control, because with a cloud-managed certificate there’s no .p12 to hand to a build server in the traditional sense, so a pipeline that signs with Fastlane or a custom script usually still needs a local identity. If you inherit a project whose archive worked on one person’s machine and nowhere else, check whether it was quietly relying on cloud signing, because the build will fail on a clean runner with a message that doesn’t mention it.

You can force local signing by adding an active Apple Distribution certificate to your keychain or by using manual signing, which Apple documents as the way to override cloud signing. Whichever route you pick, write it down, because the choice decides who can ship when the original developer is gone.

How does Fastlane match change the picture?

It moves the certificate and profiles out of one person’s keychain and into shared storage the whole team and CI can read. Fastlane’s documentation says match can store them in a private git repository, Google Cloud Storage or Amazon S3, and that for git storage the files are encrypted with OpenSSL using a passphrase. That passphrase is required the first time on each new machine, and you can set it through the MATCH_PASSWORD environment variable to avoid the prompt in CI.

Match also has a read-only mode, and Fastlane recommends using it on CI so a build server fetches the existing certificate and profiles instead of generating new ones. That one setting prevents the classic accident where a CI job creates a fresh distribution certificate, hits the team limit, and starts revoking things. The docs describe the call as match with type appstore and readonly set for CI runs.

Match can repair expired credentials, and its renew_expired_certs option, which is off by default, will remove an expired certificate from storage and create a new one. The documentation notes that the old certificate isn’t revoked on the Developer Portal when that happens. So you can end up with a pile of dead certificates in the portal, which matters because of the per-team limit.

Be careful with the nuke command. Fastlane describes match nuke as revoking certificates and provisioning profiles for an environment, and it says apps already in the App Store or TestFlight keep working while ad hoc and enterprise builds are disabled. It asks you to confirm the list first, and on a rescued app I’d treat it as a last step, taken only after you know exactly what depends on those certificates.

If the project already uses match, the first job is finding the storage location and the passphrase. A repository nobody can decrypt is the same as a lost private key, only better hidden.

How do you check the certificate on an app you didn’t build?

Start in the portal, since it tells you what exists, and then check the machines, since they tell you what works. Under Certificates, Identifiers & Profiles, open the certificate list and note every Apple Distribution entry, its expiration date, the name of whoever created it and whether it has the Managed suffix. A certificate created by a person who no longer works with you is a flag, even if it’s still valid.

Then open the provisioning profiles and find the App Store profile for the app’s bundle identifier. Check which certificate it references and whether the profile shows as active or invalid. An invalid profile after a revocation is expected, but an invalid one on an app nobody touched usually means the certificate expired.

After that, look at where signing happens today. Read the CI pipeline for the step that installs the certificate, whether it pulls a .p12 from secrets, calls match, or relies on automatic signing. If there’s no pipeline, find out which machine produced the last release, because that machine may hold the only private key.

Finally, run a test archive and a test upload to TestFlight before you need to ship something urgent. The build number rules can also reject an upload even when signing is fine, so keep both in mind when you read an upload error. A rejected binary after a successful upload is a different problem again, and the App Store rejection reasons article helps you tell them apart.

What should you set up so this doesn’t happen again?

Put a date on the calendar well before the expiration date, and put the signing identity somewhere more durable than one laptop. The expiration date is visible in the portal, so a reminder a month or two ahead costs nothing and turns an emergency into a routine task. Apple’s own cloud-managed approach renews 90 days ahead, which is a hint about how much lead time they consider sensible.

Keep at least two people with Admin on the Apple account, and make sure one of them isn’t a contractor. Store an encrypted export of the signing identity, or the match repository and its passphrase, in a secret manager the company controls. Document where signing happens, who can rotate it and what the steps are, in the repository where the next engineer will look.

This is also a place where escrow-style thinking pays off. A signing key that exists only on a former employee’s machine is the sort of gap our article on source code escrow describes, because having the source doesn’t help if you can’t sign the build. It’s worth asking for the signing details at the same time as the repository access.

If you are taking over an app and the signing setup is the part nobody can explain, that’s the situation the RapidLabs app takeover service is built for. The RapidLabs maintenance audit also reviews who holds the keys, the roles on the store accounts and whether a release can be built from a clean machine. The certificate is a small item to fix once and a costly one to rediscover on the day a customer is waiting for a fix.