# ITMS-90034 hiba: Missing or invalid signature javítása

> ITMS-90034: a buildod nincs érvényes terjesztési tanúsítvánnyal aláírva. Nézd meg codesignnal, majd készíts új store buildet EAS-sel.

Eredeti oldal: [ITMS-90034 hiba: Missing or invalid signature javítása](https://devoria.fr/hu/blog/itms-90034-missing-or-invalid-signature-javitasa)
Szerző: [Mehdi Azizi](https://devoria.fr/hu/mehdi-azizi)
Megjelenés: 2026-11-04
A tartalom utolsó frissítése: 2026-11-04


ITMS-90034 akkor jön, amikor elküldöd a buildedet az App Store Connectbe. Azt jelenti, hogy az appod vagy valamelyik összetevője nincs Apple beküldési tanúsítvánnyal aláírva, vagyis nincs érvényes terjesztési (distribution) tanúsítványa. **A javítás: megtalálni, melyik bundle van rosszul aláírva és miért, aztán újra buildelni App Store-ra aláírva.**

Ez az útmutató a hibánál marad. Ha a tanúsítvány és a profil fogalma nem teljesen tiszta, előbb olvasd el ezt: [iOS fejlesztői tanúsítvány és provisioning profile](https://devoria.fr/hu/blog/ios-fejlesztoi-tanusitvany-provisioning-profile-expo). Itt megtalálod, hogyan olvasd az üzenetet, egy döntési fát, az IPA-dat vizsgáló parancsokat és a javítást az EAS által kezelt hitelesítő adatokkal. Az EAS-es részhez elolvastam az EAS CLI 24.10.0 kódját, ami a tanúsítványt kiválasztja.

## Mit jelent az ITMS-90034 hiba?

Ez a klasszikus formája, példanevekkel:

> 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.

2026-ban az Apple fórumán így is felbukkan: „Validation failed (409) Missing or invalid signature”, utána ugyanaz a szöveg és „(ID: 90034)”.

A „beküldési tanúsítvány” a terjesztési tanúsítványt jelenti. [Az Apple tanúsítványokról szóló súgója](https://developer.apple.com/help/account/certificates/certificates-overview) le is írja: a fejlesztői tanúsítványokkal a saját eszközeiden futtatod az appot, a terjesztésiekkel terjeszted, vagy elküldöd az App Store Connectbe.

**Olvasd el az idézett útvonalat: ez mutatja a hibás bundle-t.** A `Payload/MyApp.app` magát az appot jelöli. A `.appex` végű útvonal egy bővítményt, például widgetet. A `.framework` végű egy beágyazott könyvtárat.

Ez nem egy reviewer elutasítása. Az ellenőrzés a feltöltéskor vagy a build feldolgozása közben fut, még TestFlight előtt: ez a build soha nem jut el a tesztelőidhez.

## A döntési fa: az üzenettől a javításig

Minden sor egy jelnek felel meg, amit az üzenetben, a következő rész parancsaiban vagy az EAS naplóiban látsz. Sorban haladj: az első egyező sor adja az irányt.

| Amit látsz               | Valószínű ok             | Javítás                      |
| ------------------------ | ------------------------ | ---------------------------- |
| `.appex` végű útvonal    | Rosszul aláírt bővítmény | Bővítmény deklarálása        |
| `Signature=adhoc`        | Aláíratlan build         | Build store profillal        |
| `Apple Development`      | Fejlesztői build         | Build store profillal        |
| `ProvisionedDevices` van | Belső (ad hoc) build     | Build store profillal        |
| `sealed resource`        | Utólag módosított IPA    | Új build                     |
| EAS: „no longer valid”   | Visszavont tanúsítvány   | Új tanúsítvány               |
| Minden érvényes          | Apple oldali hiba        | Újraküldés, aztán bejelentés |

## Az IPA vizsgálata négy paranccsal

Töltsd le az IPA-t a build oldaláról az expo.dev-en, aztán nyiss egy terminált a Maceden.

**1. Ki írta alá az appot?**

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

A `codesign` a hibakimenetre ír, ezért kell a `2>&1`. [Az Apple TN3161-es technikai jegyzete](https://developer.apple.com/documentation/technotes/tn3161-inside-code-signing-certificates) szerint minden `Authority` sor a bizalmi lánc egy eleme. Az elsőnek `Apple Distribution:` vagy `iPhone Distribution:` kezdetűnek kell lennie, utána a csapatod neve. A második a régi iOS Distribution típus felirata: a kódja alapján az EAS CLI 24.10.0 még ilyen típusú tanúsítványokat hoz létre. Ha `Apple Development:` szerepel, az fejlesztői build. Ha `Signature=adhoc` szerepel, `Authority` sor nélkül, akkor a binárist semmilyen tanúsítvány nem írta alá.

**2. Módosult az app az aláírás után?**

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

Azt szeretnéd látni, hogy `valid on disk`, utána `satisfies its Designated Requirement`. A TN3161 pontosítja, mit garantál ez az ellenőrzés: minden várt fájl megvan, semmi nem került hozzá, semmi nem módosult. Egy általam aláírt, majd utólag megpiszkált teszt bundle-nél a parancs ezt válaszolja: `a sealed resource is missing or invalid`, aztán `file modified:` és a módosított fájl. A `--deep` kapcsoló itt ellenőrzésre való, aláírásra soha: az Apple fórumán a támogatási csapat egyik mérnöke ellenzi az aláíráshoz.

**3. Melyik profil van beágyazva?**

```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
```

Ezek [a profilokról szóló TN3125-ös jegyzet](https://developer.apple.com/documentation/technotes/tn3125-inside-code-signing-provisioning-profiles) parancsai. Egy App Store profil nem tartalmaz eszközlistát: a második sornak `Could not extract value` választ kell adnia. Ha eszközazonosítókat mutat, az ad hoc profil, egy belső buildé. A harmadik a profil lejárati dátumát adja meg.

**4. A bővítmények és frameworkök ugyanúgy vannak aláírva?**

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

Minden összetevőnek ugyanazt az `Authority` sort kell mutatnia, mint az appnak. Ha valamelyik eltér, azt nevezi meg az üzenet.

Ha feltöltés előtt akarsz ellenőrizni, a TN3161 az `altool`-t ajánlja, ugyanazt az ellenőrzést, mint az Xcode Validate App gombja. Ehhez App Store Connect API-kulcs kell, aminek az `AuthKey_<KEY_ID>.p8` fájlja a `~/.appstoreconnect/private_keys` mappába kerül:

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

## Javítás EAS-sel, okonként

### Belső vagy fejlesztői build ment az Apple-nek

Az [Expo eas.json dokumentációja](https://docs.expo.dev/build/eas-json/) szerint a `"distribution": "internal"` buildek nincsenek store-okra aláírva: ad hoc profilt használnak. Csak a `store` terjesztésű profil (ez az alapértelmezés) ad feltölthető buildet. **A legbiztosabb, ha azt a buildet küldöd el, amit épp most készítettél, kézi választás nélkül**:

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

Ha `eas submit --path`-szal küldesz, ellenőrizd, hogy a fájl tényleg a legutóbbi store buildod. Az Apple fórumán egy csapat rájött, hogy a feltöltőeszközük minden alkalommal egy régi, gitben tárolt IPA-t küldött el.

### Elfelejtett bővítmény

Minden bővítmény külön bundle, saját azonosítóval és saját profillal. Natív generálású Expo projektben az [Expo iOS bővítményekről szóló oldala](https://docs.expo.dev/build-reference/app-extensions/) azt kéri, hogy deklaráld őket az `extra.eas.build.experimental.ios.appExtensions` alatt. Így az EAS CLI már a build előtt ismeri őket, és létrehozza vagy ellenőrzi az azonosítóikat. A legtöbb könyvtár, ami bővítményt ad hozzá, a pluginjával ezt a deklarációt megírja helyetted.

A Solys, a minijátékos ébresztőm, négy bővítményt tartalmaz: egy widgetet és három Képernyőidő-bővítményt. Mind a négy deklarálva van a konfigurációjában, és az EAS-nek mindegyikhez van profilja. **Egy kézzel, Xcode-ban hozzáadott bővítmény ilyen deklaráció nélkül a tökéletes gyanúsított**, ha az üzenetben `.appex` útvonal szerepel.

### Visszavont vagy lejárt tanúsítvány

Az [Apple tanúsítványokról szóló oldala](https://developer.apple.com/support/certificates/) egyértelmű: lejárt vagy visszavont tanúsítvánnyal aláírt buildet már nem küldhetsz be. Egy már feltöltött, de még be nem küldött build akár Invalid Binary állapotba is kerülhet, ha a tanúsítványát visszavonták.

Az EAS CLI 24.10.0 kódjából kiderül, mikor marad ez észrevétlen:

- **Interaktív build, Apple-be bejelentkezve**: az EAS összeveti a tanúsítványát az Apple-nél még érvényesekkel. Ha már nincs ott, kiírja: „Current distribution certificate is no longer valid in Apple Dev Portal”, és felajánlja, hogy válassz vagy hozz létre egyet.
- **Interaktív build, bejelentkezés nélkül**: az EAS csak a dátumokat nézi, és figyelmeztet, hogy kihagyja az Apple-nél való ellenőrzést.
- **Nem interaktív build, CI-ban**: az EAS kiírja: „Distribution Certificate is not validated for non-interactive builds”, és ettől még aláír.

**CI-ban az EAS nem ellenőrzi újra magát a tanúsítványt: a visszavonás lehet, hogy csak feltöltéskor derül ki.** A javítás: indíts egy interaktív buildet az Apple-fiókodba bejelentkezve, vagy használd az `eas credentials --platform ios` parancsot, Build Credentials menü, aztán „Distribution Certificate: Add a new one to your account”. A régi tanúsítványt tartalmazó profilok érvénytelenné válnak: az EAS a következő buildnél ellenőrzi és újragenerálja őket. Az Apple tanúsítványszám-korlátairól az [iOS fejlesztői tanúsítványról szóló útmutatóban](https://devoria.fr/hu/blog/ios-fejlesztoi-tanusitvany-provisioning-profile-expo) olvashatsz.

### Az aláírás után módosított bináris

Az aláírás hashekkel pecsételi le a kódot, az erőforrásokat és a metaadatokat, ahogy [az Apple TN3126-os jegyzete](https://developer.apple.com/documentation/technotes/tn3126-inside-code-signing-hashes) elmagyarázza. Ha kicsomagolod az IPA-t, módosítasz egy fájlt, majd újra becsomagolod, eltöröd ezt a pecsétet. **A módosítást a konfigurációdban végezd el, aztán buildelj újra.** Az EAS által készített IPA-hoz soha ne nyúlj.

Ugyanez a logika, ha kód rossz helyre került, például egy `.zip` archívumba: az App Store nem tudja újra aláírni. Az engedélyezett helyeket az Apple [a bundle tartalmáról](https://developer.apple.com/documentation/bundleresources/placing-content-in-a-bundle) szóló oldalán írja le.

### Helyi hitelesítő adatok

Ha az EAS profilod `"credentialsSource": "local"` beállítást használ, a `credentials.json` fájlod egy `.p12` tanúsítványra és egy `.mobileprovision` profilra mutat. Ellenőrizd a profilt a 3. lépés parancsaival: App Store típusúnak kell lennie, és a jelenlegi terjesztési tanúsítványodat kell tartalmaznia. Ezeket a fájlokat pedig tartsd a repón kívül, ahogy [egy Expo app API-kulcsait](https://devoria.fr/hu/blog/titkos-api-kulcs-expo-app) is.

### Ha minden érvényes

Marad egy bosszantó eset. Az Apple fórumán vannak fejlesztők, akiknél a hiba eltűnik, ha ugyanazt a buildet változtatás nélkül újraküldik. 2026 augusztusában és szeptemberében két szál az ellenkezőjét írja le: új tanúsítvány és profil, ellenőrzött aláírás, mégis tartós hiba. Az egyikben egy Apple-mérnök hibajelentést javasol az IPA-val, az aláírás-elemzéssel és a Transporter naplóival, majd kapcsolatfelvételt az App Store Connecttel.

Küldd el tehát még egyszer, új buildszámmal. Ha a hiba visszatér, pedig a négy parancsod tiszta eredményt ad, jelentsd az Apple-nek ezekkel az anyagokkal. **Ne vond vissza reflexből a tanúsítványodat**: semmit nem old meg, viszont érvényteleníti a profiljaidat.

## Build feltöltése kellemetlen meglepetések nélkül

Egy aláírást két perc alatt ellenőrzöl feltöltés előtt. A többi automatikus ellenőrzés ugyanilyen alaposságot kíván, például az [ITMS-90725](https://devoria.fr/hu/blog/itms-90725-sdk-version-issue-javitasa-expo) az Xcode verzióhoz vagy az [ITMS-90683](https://devoria.fr/hu/blog/itms-90683-missing-purpose-string-expo) az engedélykérő szövegekhez. A teljes út a buildtől a feltöltésig, Mac nélkül: [iOS app publikálása Mac nélkül](https://devoria.fr/hu/blog/ios-app-kozzetetele-mac-nelkul-expo-eas).

Egy reviewer elutasítása több rálátást igényel: a teendőket az [Apple által elutasított alkalmazás](https://devoria.fr/hu/expertise/apple-altal-elutasitott-alkalmazas) oldalon találod, a leggyakoribb okokat pedig itt: [miért utasítja el az Apple az appot](https://devoria.fr/hu/blog/apple-elutasitas-miert-utasitottak-el-az-appodat).

Hogy feltöltés előtt átnézd az anyagodat, a [Review Kit](https://devoria.fr/hu/kits/app-review) összegyűjti a checklistemet és Claude Code skilleket, amik átnézik a projektedet. Ha elakadt a feltöltés, és emberi szemre van szükséged, [foglalj velem egy órát](https://devoria.fr/hu/coaching): videóhívásban, a te képernyődön átnézzük a projektedet. Ha pedig az első megjelenésedre készülsz, [csináld meg az ingyenes diagnózist](https://devoria.fr/hu/diagnostic): sorba rakja a lépéseket, és elküldi neked az Apple-elutasítás elleni checklistemet.

## Gyakori kérdések

### Az ITMS-90034 egy App Review elutasítás?

Nem. Ez egy automatikus ellenőrzés a build feltöltésekor, TestFlight és bármilyen review előtt. Senki nem nyitotta meg az appodat: az Apple csak azt állapította meg, hogy az aláírása nem érvényes terjesztési tanúsítványtól származik.

### Vissza kell vonnom a terjesztési tanúsítványomat az ITMS-90034 javításához?

Csak akkor, ha kompromittálódott vagy már érvénytelen. Egy működő tanúsítvány visszavonása érvényteleníti a profiljaidat, az okot pedig nem javítja. Kezdd azzal, hogy `codesign`-nal elolvasod az IPA aláírását, aztán javítsd, amire a döntési fa mutat.

### Javítható az ITMS-90034 távoli frissítéssel?

Nem. Az aláírás a bináris része, és az elutasított build soha nem lesz használható. Új, helyesen aláírt binárist kell készítened és újra elküldened.

### Miért a widgetemet nevezi meg a hiba, és nem az appot?

Mert a widget külön bundle, saját profillal aláírva. Ha nincs deklarálva az EAS-nek, vagy máshogy írták alá, az egész feltöltést elbuktatja. Deklaráld a bővítményt a konfigurációdban, és buildelj újra.

### Mit tegyek, ha a codesign szerint minden érvényes?

Ellenőrizd a beágyazott profilt és minden bővítményt is. Ha minden tiszta, küldd el még egyszer új buildszámmal. Ha a hiba megmarad, küldj jelentést az Apple-nek az IPA-val, a `codesign` kimenetével és a feltöltési naplókkal.


## A projekted

[Review Kit](https://devoria.fr/hu/kits/app-review): Az App Store review checklistem, a javított Apple-elutasításaim, a Google Play checklist és három Claude Code skill. 17 990 Ft.

[iOS & Android Kit](https://devoria.fr/hu/kits/ios): Készítsd el iPhone- és Android-appodat Claude Code-dal: az appjaim kezdőkódja, az út a store-okig és az összes kit. 35 990 Ft.

[Diagnózis: mi választ el az iPhone-appodtól](https://devoria.fr/hu/diagnostic): 7 kérdés, 60 másodperc: megtudod, mi akadályoz valójában abban, hogy kiadd az iPhone-appodat, megkapod a 4 lépéses utadat és a hozzád illő kitet.