# ITMS-90034: fiks «Missing or invalid signature»

> ITMS-90034: builden din er ikke signert med et gyldig distribusjonssertifikat. Les signaturen med codesign, og lag en ny store-build med EAS.

Opprinnelig side: [ITMS-90034: fiks «Missing or invalid signature»](https://devoria.fr/no/blog/itms-90034-missing-or-invalid-signature-fiks)
Forfatter: [Mehdi Azizi](https://devoria.fr/no/mehdi-azizi)
Publisert: 2026-11-04
Innhold sist revidert: 2026-11-04


ITMS-90034 dukker opp når du sender builden din til App Store Connect. Den sier at appen din, eller en av delene i den, ikke er signert med et Apple submission certificate, altså et gyldig distribusjonssertifikat. **Løsningen: finn ut hvilken bundle som er feil signert og hvorfor, og lag deretter en ny build signert for App Store.**

Denne guiden holder seg til selve feilen. Hvis ordene sertifikat og profil er litt uklare for deg, les først [iOS-utviklersertifikat og provisioning profile](https://devoria.fr/no/blog/ios-utviklersertifikat-provisioning-profile-expo). Her finner du meldingen du skal lese, et beslutningstre, kommandoene som inspiserer IPA-en din og løsningen med legitimasjon som EAS håndterer. For EAS-delen har jeg lest koden i EAS CLI 24.10.0 som velger sertifikatet.

## Hva betyr feilen ITMS-90034?

Her er den vanlige formen, med eksempelnavn:

> ITMS-90034: Missing or invalid signature. The bundle 'com.example.myapp' at bundle path 'Payload/MyApp.app' is not signed using an Apple submission certificate.

I 2026 dukker den også opp på Apples forum som «Validation failed (409) Missing or invalid signature», etterfulgt av den samme teksten og «(ID: 90034)».

«Submission certificate» er distribusjonssertifikatet. [Apples hjelpesider om sertifikater](https://developer.apple.com/help/account/certificates/certificates-overview) sier det rett ut: utviklingssertifikater brukes til å kjøre appen på dine egne enheter, distribusjonssertifikater til å distribuere den eller sende den til App Store Connect.

**Les stien som nevnes: den peker på bundelen som er feil.** `Payload/MyApp.app` gjelder selve appen. En sti som slutter på `.appex` gjelder en utvidelse, for eksempel en widget. En sti på `.framework` gjelder et innebygd bibliotek.

Dette er ikke en avvisning fra en reviewer. Valideringen slår til ved opplasting eller mens builden behandles, før TestFlight: denne builden kommer aldri frem til testerne dine.

## Beslutningstreet: fra melding til løsning

Hver rad tilsvarer et tegn du ser i meldingen, i kommandoene i neste seksjon eller i EAS-loggene. Gå gjennom dem i rekkefølge: den første som passer, viser deg veien.

| Det du ser                  | Sannsynlig årsak       | Løsning                    |
| --------------------------- | ---------------------- | -------------------------- |
| Sti på `.appex`             | Feil signert utvidelse | Deklarer utvidelsen        |
| `Signature=adhoc`           | Usignert build         | Build med store-profil     |
| `Apple Development`         | Utviklingsbuild        | Build med store-profil     |
| `ProvisionedDevices` funnet | Intern build (ad hoc)  | Build med store-profil     |
| `sealed resource`           | IPA endret i etterkant | Lag builden på nytt        |
| EAS: «no longer valid»      | Tilbakekalt sertifikat | Nytt sertifikat            |
| Alt er gyldig               | Feil hos Apple         | Send på nytt, så rapporter |

## Inspiser IPA-en din med fire kommandoer

Last ned IPA-en fra build-siden på expo.dev, og åpne en terminal på Mac-en din.

**1. Hvem signerte appen?**

```bash
unzip -q MyApp.ipa -d ipa
codesign -dv --verbose=4 ipa/Payload/*.app 2>&1 | grep -E "^(Identifier|Authority|Signature|TeamIdentifier)="
```

`codesign` skriver til standard error, derav `2>&1`. Ifølge [Apples tekniske notat TN3161](https://developer.apple.com/documentation/technotes/tn3161-inside-code-signing-certificates) er hver `Authority`-linje et ledd i tillitskjeden. Den første må begynne med `Apple Distribution:` eller `iPhone Distribution:`, etterfulgt av navnet på teamet ditt. Den andre betegnelsen hører til den gamle typen iOS Distribution: ifølge koden lager EAS CLI 24.10.0 fortsatt sertifikater av denne typen. Ser du `Apple Development:`, er det en utviklingsbuild. Ser du `Signature=adhoc` uten noen `Authority`-linje, er binærfilen ikke signert med noe sertifikat.

**2. Er appen endret etter signeringen?**

```bash
codesign --verify --deep --strict -vv ipa/Payload/*.app
```

Du vil se `valid on disk`, og deretter `satisfies its Designated Requirement`. TN3161 forklarer hva denne sjekken garanterer: alle forventede filer er der, ingen er lagt til, ingen er endret. På en testbundle jeg signerte og så endret, svarer kommandoen `a sealed resource is missing or invalid`, og deretter `file modified:` etterfulgt av den endrede filen. Flagget `--deep` er her bare for å verifisere, aldri for å signere: på Apples forum fraråder en ingeniør fra supportteamet å bruke det til signering.

**3. Hvilken profil er bygd inn?**

```bash
security cms -D -i ipa/Payload/*.app/embedded.mobileprovision -o profil.plist
plutil -extract ProvisionedDevices xml1 -o - profil.plist
plutil -extract ExpirationDate raw profil.plist
```

Dette er kommandoene fra [notatet TN3125 om profiler](https://developer.apple.com/documentation/technotes/tn3125-inside-code-signing-provisioning-profiles). En App Store-profil inneholder ingen enhetsliste: den andre linjen skal svare `Could not extract value`. Viser den enhets-ID-er, er det en ad hoc-profil, altså en intern build. Den tredje gir utløpsdatoen til profilen.

**4. Er utvidelsene og rammeverkene signert likt?**

```bash
find ipa/Payload/*.app \( -name "*.appex" -o -name "*.framework" \) \
  -exec sh -c 'echo "$1"; codesign -dvv "$1" 2>&1 | grep -m1 "^Authority="' _ {} \;
```

Hver komponent skal vise samme `Authority`-linje som appen. Hvis én av dem avviker, er det den meldingen nevner.

Vil du sjekke før opplasting, anbefaler TN3161 `altool`, den samme kontrollen som Validate App-knappen i Xcode. Den krever en App Store Connect API-nøkkel, der filen `AuthKey_<KEY_ID>.p8` legges i `~/.appstoreconnect/private_keys`:

```bash
xcrun altool --validate-app -f MyApp.ipa -t ios --api-key <KEY_ID> --api-issuer <ISSUER_ID>
```

## Fiks det med EAS, årsak for årsak

### En intern build eller utviklingsbuild sendt til Apple

Ifølge [Expos dokumentasjon om eas.json](https://docs.expo.dev/build/eas-json/) er builds med `"distribution": "internal"` ikke signert for butikkene: de bruker en ad hoc-profil. Bare en profil med distribusjon `store`, som er standardverdien, gir en build du kan sende inn. **Det sikreste er å sende builden du nettopp har laget, uten å velge den manuelt**:

```bash
eas build --platform ios --profile production --auto-submit
```

Bruker du `eas submit --path`, sjekk at filen faktisk er din siste store-build. På Apples forum oppdaget et team at opplastingsverktøyet deres sendte en gammel IPA hver gang, en som lå versjonert i git.

### En glemt utvidelse

Hver utvidelse er en egen bundle, med egen identifikator og egen profil. I et Expo-prosjekt med native generering ber [Expos side om iOS-utvidelser](https://docs.expo.dev/build-reference/app-extensions/) deg deklarere dem i `extra.eas.build.experimental.ios.appExtensions`. Da kjenner EAS CLI dem før builden, og oppretter eller validerer legitimasjonen deres. De fleste biblioteker som legger til en utvidelse, skriver denne deklarasjonen for deg via sin plugin.

Solys, vekkerklokka mi med minispill, har fire utvidelser: en widget og tre Skjermtid-utvidelser. Alle fire er deklarert i konfigurasjonen, og EAS har en profil for hver av dem. **En utvidelse lagt til manuelt i Xcode, uten denne deklarasjonen, er den perfekte kandidaten** når meldingen viser en sti på `.appex`.

### Et tilbakekalt eller utløpt sertifikat

[Apples side om sertifikater](https://developer.apple.com/support/certificates/) er tydelig: du kan ikke lenger laste opp en build signert med et utløpt eller tilbakekalt sertifikat. En build som allerede er lastet opp, men ikke sendt til gjennomgang, kan til og med gå over til Invalid Binary hvis sertifikatet er tilbakekalt.

Koden i EAS CLI 24.10.0 viser når dette går ubemerket hen:

- **Interaktiv build, logget inn hos Apple**: EAS sammenligner sertifikatet med dem som fortsatt er gyldige hos Apple. Er det ikke der lenger, viser den «Current distribution certificate is no longer valid in Apple Dev Portal» og lar deg velge eller lage et nytt.
- **Interaktiv build, uten innlogging**: EAS sjekker bare datoene og advarer om at den hopper over valideringen hos Apple.
- **Ikke-interaktiv build, i CI**: EAS viser «Distribution Certificate is not validated for non-interactive builds» og signerer likevel.

**I CI sjekker ikke EAS selve sertifikatet på nytt: en tilbakekalling kan først vise seg ved opplasting.** Løsningen: kjør en interaktiv build logget inn med Apple-kontoen din, eller bruk `eas credentials --platform ios`, menyen Build Credentials, og deretter «Distribution Certificate: Add a new one to your account». Profilene som inneholdt det gamle sertifikatet, blir ugyldige: EAS sjekker dem ved neste build og lager dem på nytt. Apples grenser for antall sertifikater er forklart i [guiden om iOS-utviklersertifikatet](https://devoria.fr/no/blog/ios-utviklersertifikat-provisioning-profile-expo).

### En binærfil endret etter signering

Signaturen forsegler koden, ressursene og metadataene med hasher, som [Apples notat TN3126](https://developer.apple.com/documentation/technotes/tn3126-inside-code-signing-hashes) forklarer. Å pakke ut IPA-en for å endre en fil og så pakke den sammen igjen bryter forseglingen. **Gjør endringen i konfigurasjonen din, og lag builden på nytt.** Rør aldri IPA-en som EAS har laget.

Samme logikk gjelder for kode som ligger på feil sted, for eksempel i et `.zip`-arkiv: App Store kan ikke signere den på nytt. Apple beskriver de tillatte plasseringene på siden om [innholdet i en bundle](https://developer.apple.com/documentation/bundleresources/placing-content-in-a-bundle).

### Lokal legitimasjon

Hvis EAS-profilen din bruker `"credentialsSource": "local"`, peker `credentials.json`-filen din til et `.p12`-sertifikat og en `.mobileprovision`-profil. Sjekk profilen med kommandoene fra steg 3: den må være av typen App Store og inneholde det nåværende distribusjonssertifikatet ditt. Og hold disse filene utenfor repoet, akkurat som [API-nøklene i en Expo-app](https://devoria.fr/no/blog/hemmelig-api-nokkel-expo-app).

### Når alt er gyldig

Det gjenstår ett frustrerende tilfelle. På Apples forum ser utviklere at feilen forsvinner når de sender den samme builden på nytt, uten å endre noe. I august og september 2026 beskriver to tråder det motsatte: nytt sertifikat og ny profil, verifisert signatur, feilen står fast. I én av dem anbefaler en Apple-ingeniør en feilrapport med IPA-en, signaturanalysen og Transporter-loggene, og deretter å kontakte App Store Connect.

Send derfor på nytt én gang med et nytt build-nummer. Kommer feilen tilbake selv om de fire kommandoene dine er rene, rapporter den til Apple med disse vedleggene. **Ikke tilbakekall sertifikatet ditt på refleks**: det løser ingenting mer, og det gjør profilene dine ugyldige.

## Send builden din uten ubehagelige overraskelser

En signatur sjekkes på to minutter før opplasting. De andre automatiske kontrollene krever samme grundighet, som [ITMS-90725](https://devoria.fr/no/blog/itms-90725-sdk-version-issue-expo) for Xcode-versjonen eller [ITMS-90683](https://devoria.fr/no/blog/itms-90683-missing-purpose-string-expo) for tillatelsestekstene. Hele veien fra build til opplasting, uten Mac, finner du i [publiser en iOS-app uten Mac](https://devoria.fr/no/blog/publisere-ios-app-uten-mac-expo-eas).

Avvisninger fra en reviewer krever mer ettertanke: fremgangsmåten står på siden [app avvist av Apple](https://devoria.fr/no/expertise/app-avvist-av-apple), og de vanligste årsakene finner du i [hvorfor Apple avviser en app](https://devoria.fr/no/blog/avvist-av-apple-hvorfor-appen-blir-avvist).

For å sjekke prosjektet ditt før opplasting samler [Review Kit](https://devoria.fr/no/kits/app-review) sjekklisten min og Claude Code-skills som går gjennom prosjektet ditt. Står opplastingen fast og du vil ha et menneskelig blikk, [book en time med meg](https://devoria.fr/no/coaching): vi går gjennom prosjektet ditt på video, på din skjerm. Og forbereder du din første lansering, [ta den gratis diagnosen](https://devoria.fr/no/diagnostic): den setter stegene i riktig rekkefølge og sender deg sjekklisten min mot avvisning fra Apple.

## Ofte stilte spørsmål

### Er ITMS-90034 en avvisning fra App Review?

Nei. Det er en automatisk validering som skjer når builden lastes opp, før TestFlight og før noen gjennomgang. Ingen har åpnet appen din: Apple har bare sett at signaturen ikke kommer fra et gyldig distribusjonssertifikat.

### Må jeg tilbakekalle distribusjonssertifikatet mitt for å fikse ITMS-90034?

Bare hvis det er kompromittert eller allerede ugyldig. Å tilbakekalle et sertifikat som fungerer, gjør profilene dine ugyldige uten å fikse årsaken. Start med å lese signaturen til IPA-en din med `codesign`, og fiks så det beslutningstreet peker på.

### Kan man fikse ITMS-90034 med en oppdatering over nett?

Nei. Signaturen er en del av binærfilen, og den avviste builden blir aldri brukbar. Du må lage en ny, riktig signert binærfil og sende den på nytt.

### Hvorfor nevner feilen widgeten min og ikke appen?

Fordi widgeten er en egen bundle, signert med sin egen profil. Hvis den ikke er deklarert for EAS eller er signert på en annen måte, får den hele opplastingen til å feile. Deklarer utvidelsen i konfigurasjonen din og lag builden på nytt.

### Hva gjør jeg hvis codesign sier at alt er gyldig?

Sjekk også den innebygde profilen og hver utvidelse. Er alt rent, send på nytt én gang med et nytt build-nummer. Står feilen fast, send en rapport til Apple med IPA-en, utdataene fra `codesign` og opplastingsloggene.


## Prosjektet ditt

[Review Kit](https://devoria.fr/no/kits/app-review): Sjekklisten min for App Store-gjennomgang, Apples avslag på appene mine med rettelser, sjekklisten for Google Play og tre Claude Code-skills. 499 kr.

[iOS & Android Kit](https://devoria.fr/no/kits/ios): Lag din iPhone- og Android-app med Claude Code: startkoden fra appene mine, veien helt til butikkene og alle kitene. 999 kr.

[Diagnose: dette står mellom deg og iPhone-appen din](https://devoria.fr/no/diagnostic): 7 spørsmål, 60 sekunder: du får vite hva som egentlig hindrer deg i å publisere iPhone-appen din, veien din i 4 steg og kitet som passer deg.