skip to content

In an EAS project, what happens to live apps and future builds when an iOS distribution certificate, a provisioning profile or the Android upload key is revoked, expires or leaks?

level: seniorimportance: should knowfreq 22%

answer

  1. build-time vs run-time credentials
  2. iOS signing assets: regenerate freely
  3. profile expires yearly; certificate revocation voids profiles
  4. Android upload key: reset via Play support
  5. CI non-interactive cannot regenerate alone

basics

~20 s

iOS distribution certificates and provisioning profiles are used only at build time, so expiry or revocation never breaks live apps; they are regenerated with eas credentials. Replacing a lost or leaked Android upload key needs a Play upload key reset.

solid answer

~50 s

I sort credentials by when they are used. The iOS **distribution certificate** and **provisioning profile** are build-time only: expiry or revocation leaves apps on the App Store untouched and only blocks new builds. Profiles expire after 12 months and the next `eas build -p ios` or `eas credentials` regenerates them; revoking the certificate invalidates the profiles built on it, so both are recreated. The iOS **push key** is run-time: revoking it stops notifications until a replacement is uploaded. The Android **upload key** is permanent in practice: if it leaks or is lost, Play App Signing lets you ask Google support to register a new one, while Google's app signing key is unaffected. Deleting in `eas credentials` removes only EAS's copy; revocation happens in Apple's portal. In CI, regenerating a profile non-interactively needs an App Store Connect API key, and `--freeze-credentials` makes iOS builds fail instead of changing a profile.

code

bash · 9 lines
bash
# Inspect or replace credentials (interactive)
eas credentials -p ios

# Register a new test iPhone, then re-sign an existing ad hoc build for it
eas device:create
eas build:resign

# CI: never let an iOS build change its provisioning profile
eas build -p ios -e production --non-interactive --freeze-credentials

go deeper

for a junior

Recall that iOS certificates and profiles only sign new builds, so their expiry never breaks the app users already have.

for a middle

Explain the table: build-time versus run-time credentials, account versus app scope, the yearly profile expiry, and why deleting on EAS is not revoking at Apple.

for a senior

Show a rotation plan: regenerate iOS assets interactively, protect and back up the Android key, handle a leak with a Play upload key reset, and keep CI frozen.

for a principal

Own the incident playbook for a leaked key: who revokes what, in which console, how fast, and what monitoring confirms nothing was shipped with it.

## Two questions for every credential When a signing credential expires, is revoked or leaks, two things matter: 1. **Does anything already in users' hands break?** That depends on whether the credential is used at **build time** (only to sign a new binary) or at **run time** (by the installed app or a server). 2. **Can it be replaced freely?** Some credentials can be regenerated on demand; others are anchored in a store's record of your app. ## The iOS credentials | Credential | Used at | Scope | Expiry or revocation affects live apps? | Replacement | |---|---|---|---|---| | Distribution certificate | build time | the whole Apple Developer account | No | Create a new one; regenerate the profiles that used the old one | | Provisioning profile | build time | one bundle identifier | No | Regenerate; profiles expire after 12 months | | Push notification key | run time | the account | Yes: push stops until replaced | Create a new key and upload it; keys do not expire | Consequences worth stating in an interview: - Revoking the **distribution certificate** does not pull any app from the App Store, but every provisioning profile built on it becomes invalid, so the next build regenerates both. - An expired **provisioning profile** is routine: the next `eas build -p ios`, or `eas credentials`, creates a new one. - Adding a test device to an **ad hoc** profile means registering the device (`eas device:create`) and producing a new profile, by an interactive rebuild or by re-signing an existing build with `eas build:resign`. - Deleting a certificate or key through `eas credentials` removes **only EAS's copy**. Revocation, or freeing a slot for a new push key, is done in the Apple Developer portal. ## The Android upload key On Android the key EAS holds signs every upload to Google Play, and Play checks it against the upload certificate registered for the app. It cannot simply be regenerated: - With **Play App Signing**, Google re-signs releases with its own app signing key. If the upload key is **lost or leaked**, the team creates a new keystore, exports its certificate to PEM with `keytool -export -rfc`, and asks Google Play support to register it. Installed apps are unaffected, because their signature comes from Google's key. - **Without** Play App Signing, the key EAS holds is the app signing key itself, and losing it means the app cannot be updated; a leak is equally serious. - On EAS, the new keystore is uploaded through `eas credentials` (overwriting the old one, which the CLI backs up first) and verified by fingerprint. A leaked upload key alone does not let an attacker ship an update: they would also need access to the Play Console account or a submission credential. That is a reason to rotate promptly, not a reason to relax. ## Rotation in CI Automated builds run EAS CLI with `--non-interactive`, which changes what can happen when a credential is missing or stale: - **iOS:** without a stored distribution certificate the build fails with "Credentials are not set up. Run this command again in interactive mode." Creating or repairing a provisioning profile non-interactively requires App Store Connect API key authentication, supplied through `EXPO_ASC_API_KEY_PATH`, `EXPO_ASC_KEY_ID` and `EXPO_ASC_ISSUER_ID` or a key configured on EAS. - **`--freeze-credentials`** makes an iOS build fail rather than modify a misconfigured provisioning profile, which suits pipelines where only a person may change credentials. - **Android:** a missing keystore is generated silently in non-interactive mode, which is dangerous for an app already on Play. ## Leak response in short | Leaked credential | First action | Then | |---|---|---| | Distribution certificate `.p12` | Revoke it in the Apple Developer portal | Let the next interactive build create a new certificate and profiles | | Push key | Create a replacement, upload it, then revoke the old one | Confirm notifications still arrive | | Android upload key | Request an upload key reset through Play support | Upload the new keystore to EAS and verify fingerprints | ## A practical routine 1. Inventory credentials with `eas credentials` for both platforms and note fingerprints and expiry dates. 2. Keep an offline backup of the Android keystore; it is the only credential whose loss is expensive. 3. Regenerate iOS profiles and certificates interactively when they lapse; they carry no production risk. 4. Treat the push key as run-time infrastructure: rotate it with a replacement uploaded immediately. 5. Run credential changes by hand, and keep CI on stored credentials, with `--freeze-credentials` for iOS where appropriate.

  • Why does deleting a distribution certificate with eas credentials not stop anyone from using it?
    The command removes the certificate from EAS's servers only. From Apple's side it is still valid until it is revoked in the Apple Developer portal, so a leaked copy remains usable. Rotation means revoking at Apple, then letting EAS create or upload the replacement.
  • Why can a leaked Android upload key not, on its own, be used to push a malicious update to Play users?
    Publishing also requires access to the Play Console account or a submission credential such as a service account key. The upload key only proves who signed an upload. It still has to be replaced through a Play upload key reset, because combined with a compromised account it would allow an update.
  • What does --freeze-credentials change for a non-interactive EAS iOS build?
    If the provisioning profile is not configured correctly, the build stops with an error instead of creating or modifying credentials. It suits pipelines where credential changes must be made by a person, and it cannot be combined with `--refresh-ad-hoc-provisioning-profile`.

saying these in an interview costs you the question

  • Revoking the distribution certificate removes the app from the App Store.
  • An expired provisioning profile stops installed copies from launching.
  • Deleting credentials in eas credentials revokes them at Apple.
  • The Android upload key can be regenerated freely like an iOS profile.
  • Rotating the push key is harmless because it is not a signing credential.