# ITMS-90034: „Missing or invalid signature“ beheben > ITMS-90034: Dein Build ist nicht mit einem gültigen Distributionszertifikat signiert. Prüf die Signatur mit codesign und bau dann neu für den Store mit EAS. Originalseite: [ITMS-90034: „Missing or invalid signature“ beheben](https://devoria.fr/de/blog/itms-90034-missing-or-invalid-signature-beheben) Autor: [Mehdi Azizi](https://devoria.fr/de/mehdi-azizi) Veröffentlicht: 2026-11-04 Letzte inhaltliche Überarbeitung: 2026-11-04 ITMS-90034 taucht auf, wenn du deinen Build an App Store Connect schickst. Die Meldung sagt: Deine App oder eine ihrer Komponenten ist nicht mit einem Apple-Submission-Zertifikat signiert, also mit einem gültigen Distributionszertifikat. **Die Lösung: herausfinden, welches Bundle falsch signiert ist und warum, und dann einen neuen, für den App Store signierten Build erstellen.** Dieser Guide bleibt beim Fehler selbst. Wenn dir Begriffe wie Zertifikat und Profil noch unklar sind, lies zuerst [iOS-Entwicklerzertifikat und Provisioning Profile](https://devoria.fr/de/blog/ios-zertifikat-provisioning-profile-expo). Hier findest du die Meldung, die du lesen musst, einen Entscheidungsbaum, die Befehle, mit denen du deine IPA untersuchst, und die Lösung mit den von EAS verwalteten Credentials. Für den EAS-Teil habe ich den Code von EAS CLI 24.10.0 gelesen, der das Zertifikat auswählt. ## Was bedeutet der Fehler ITMS-90034? So sieht er klassischerweise aus, mit Beispielnamen: > 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. Im Jahr 2026 taucht er im Apple-Forum auch als „Validation failed (409) Missing or invalid signature“ auf, gefolgt vom selben Text und „(ID: 90034)“. Das „Submission-Zertifikat“ ist das Distributionszertifikat. [Apples Hilfe zu Zertifikaten](https://developer.apple.com/help/account/certificates/certificates-overview) sagt es klar: Entwicklungszertifikate dienen dazu, deine App auf deinen Geräten zu starten, Distributionszertifikate dazu, sie zu verteilen oder an App Store Connect zu schicken. **Lies den genannten Pfad: Er zeigt auf das fehlerhafte Bundle.** `Payload/MyApp.app` meint die App selbst. Ein Pfad, der auf `.appex` endet, meint eine Extension, zum Beispiel ein Widget. Ein Pfad auf `.framework` meint eine eingebettete Bibliothek. Das ist keine Ablehnung durch einen Reviewer. Die Validierung schlägt beim Upload oder während der Verarbeitung des Builds fehl, noch vor TestFlight: Dieser Build wird deine Tester nie erreichen. ## Der Entscheidungsbaum: von der Meldung zur Lösung Jede Zeile entspricht einem Hinweis, den du in der Meldung, in den Befehlen aus dem nächsten Abschnitt oder in den EAS-Logs findest. Geh sie der Reihe nach durch: Die erste, die passt, ist deine Spur. | Was du siehst | Wahrscheinliche Ursache | Lösung | | --------------------------- | -------------------------- | -------------------------- | | Pfad auf `.appex` | Extension falsch signiert | Extension deklarieren | | `Signature=adhoc` | Build nicht signiert | Build mit Store-Profil | | `Apple Development` | Entwicklungs-Build | Build mit Store-Profil | | `ProvisionedDevices` lesbar | Interner Build (ad hoc) | Build mit Store-Profil | | `sealed resource` | IPA nachträglich verändert | Neu bauen | | EAS: „no longer valid“ | Zertifikat widerrufen | Neues Zertifikat | | Alles gültig | Problem auf Apples Seite | Erneut senden, dann melden | ## Deine IPA mit vier Befehlen untersuchen Lade die IPA von der Build-Seite auf expo.dev herunter und öffne dann ein Terminal auf deinem Mac. **1. Wer hat die App signiert?** ```bash unzip -q MyApp.ipa -d ipa codesign -dv --verbose=4 ipa/Payload/*.app 2>&1 | grep -E "^(Identifier|Authority|Signature|TeamIdentifier)=" ``` `codesign` schreibt auf die Fehlerausgabe, daher das `2>&1`. Laut [Apples Technical Note TN3161](https://developer.apple.com/documentation/technotes/tn3161-inside-code-signing-certificates) ist jede `Authority`-Zeile ein Glied der Vertrauenskette. Die erste muss mit `Apple Distribution:` oder `iPhone Distribution:` beginnen, gefolgt vom Namen deines Teams. Die zweite Bezeichnung gehört zum alten Typ iOS Distribution: Laut seinem Code erstellt EAS CLI 24.10.0 immer noch Zertifikate dieses Typs. Steht da `Apple Development:`, ist es ein Entwicklungs-Build. Steht da `Signature=adhoc` ohne eine einzige `Authority`-Zeile, ist das Binary von keinem Zertifikat signiert. **2. Wurde die App nach dem Signieren verändert?** ```bash codesign --verify --deep --strict -vv ipa/Payload/*.app ``` Du willst `valid on disk` lesen, dann `satisfies its Designated Requirement`. TN3161 erklärt, was diese Prüfung garantiert: Alle erwarteten Dateien sind da, keine wurde hinzugefügt, keine verändert. Bei einem Test-Bundle, das ich signiert und danach angepasst habe, antwortet der Befehl mit `a sealed resource is missing or invalid`, dann `file modified:` gefolgt von der geänderten Datei. Die Option `--deep` dient hier nur zum Prüfen, niemals zum Signieren: Im Apple-Forum rät ein Ingenieur aus dem Support-Team davon ab, damit zu signieren. **3. Welches Profil ist eingebettet?** ```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 ``` Das sind die Befehle aus [der Technical Note TN3125 zu Profilen](https://developer.apple.com/documentation/technotes/tn3125-inside-code-signing-provisioning-profiles). Ein App-Store-Profil enthält keine Geräteliste: Die zweite Zeile muss `Could not extract value` ausgeben. Zeigt sie Geräte-IDs an, ist es ein Ad-hoc-Profil, also das eines internen Builds. Die dritte Zeile liefert das Ablaufdatum des Profils. **4. Sind Extensions und Frameworks genauso signiert?** ```bash find ipa/Payload/*.app \( -name "*.appex" -o -name "*.framework" \) \ -exec sh -c 'echo "$1"; codesign -dvv "$1" 2>&1 | grep -m1 "^Authority="' _ {} \; ``` Jede Komponente muss dieselbe `Authority`-Zeile zeigen wie die App. Weicht eine davon ab, ist sie es, die in der Meldung genannt wird. Wenn du vor dem Upload prüfen willst, empfiehlt TN3161 `altool`, also dieselbe Prüfung wie der Button Validate App in Xcode. Dafür brauchst du einen App Store Connect API-Schlüssel, dessen Datei `AuthKey_.p8` in `~/.appstoreconnect/private_keys` liegt: ```bash xcrun altool --validate-app -f MyApp.ipa -t ios --api-key --api-issuer ``` ## Mit EAS beheben, Ursache für Ursache ### Ein interner oder Entwicklungs-Build wurde an Apple geschickt Laut [Expos Dokumentation zu eas.json](https://docs.expo.dev/build/eas-json/) sind Builds mit `"distribution": "internal"` nicht für die Stores signiert: Sie nutzen ein Ad-hoc-Profil. Nur ein Profil mit Distribution `store`, dem Standardwert, erzeugt einen Build, den du hochladen kannst. **Am sichersten schickst du den Build, den du gerade gebaut hast, ohne ihn von Hand auszuwählen**: ```bash eas build --platform ios --profile production --auto-submit ``` Wenn du `eas submit --path` nutzt, prüf, dass die Datei wirklich dein letzter Store-Build ist. Im Apple-Forum hat ein Team entdeckt, dass sein Upload-Tool jedes Mal eine alte, in git eingecheckte IPA hochgeladen hat. ### Eine vergessene Extension Jede Extension ist ein eigenes Bundle, mit eigener ID und eigenem Profil. In einem Expo-Projekt mit nativer Generierung verlangt [Expos Seite zu iOS-Extensions](https://docs.expo.dev/build-reference/app-extensions/), sie in `extra.eas.build.experimental.ios.appExtensions` zu deklarieren. Dann kennt EAS CLI sie schon vor dem Build und erstellt oder validiert ihre Credentials. Die meisten Bibliotheken, die eine Extension hinzufügen, schreiben diese Deklaration über ihr Plugin für dich. Solys, mein Wecker mit Minispielen, enthält vier Extensions: ein Widget und drei Bildschirmzeit-Extensions. Alle vier sind in der Konfiguration deklariert, und EAS hat für jede ein Profil. **Eine Extension, die von Hand in Xcode hinzugefügt wurde, ohne diese Deklaration, ist der ideale Kandidat** für einen Pfad auf `.appex` in der Meldung. ### Ein widerrufenes oder abgelaufenes Zertifikat [Apples Seite zu Zertifikaten](https://developer.apple.com/support/certificates/) ist eindeutig: Mit einem abgelaufenen oder widerrufenen Zertifikat signierte Builds kannst du nicht mehr hochladen. Ein bereits hochgeladener, aber noch nicht eingereichter Build kann sogar auf Invalid Binary wechseln, wenn sein Zertifikat widerrufen wurde. Der Code von EAS CLI 24.10.0 zeigt, wann dieser Fall unbemerkt bleibt: - **Interaktiver Build, mit Apple verbunden**: EAS vergleicht sein Zertifikat mit denen, die bei Apple noch gültig sind. Ist es dort nicht mehr dabei, zeigt es „Current distribution certificate is no longer valid in Apple Dev Portal“ an und bietet dir an, eins auszuwählen oder zu erstellen. - **Interaktiver Build, ohne Verbindung**: EAS prüft nur die Daten und warnt, dass es die Validierung bei Apple überspringt. - **Nicht interaktiver Build, in der CI**: EAS zeigt „Distribution Certificate is not validated for non-interactive builds“ an und signiert trotzdem. **In der CI prüft EAS das Zertifikat selbst nicht erneut: Ein Widerruf fällt womöglich erst beim Upload auf.** Die Lösung: Starte einen interaktiven Build, verbunden mit deinem Apple-Account, oder geh über `eas credentials --platform ios`, Menü Build Credentials, dann „Distribution Certificate: Add a new one to your account“. Die Profile, die das alte Zertifikat enthielten, werden ungültig: EAS prüft sie beim nächsten Build und erstellt sie neu. Apples Limits für die Anzahl der Zertifikate findest du im [Guide zum iOS-Entwicklerzertifikat](https://devoria.fr/de/blog/ios-zertifikat-provisioning-profile-expo). ### Ein nach dem Signieren verändertes Binary Die Signatur versiegelt Code, Ressourcen und Metadaten über Hashes, wie [Apples Technical Note TN3126](https://developer.apple.com/documentation/technotes/tn3126-inside-code-signing-hashes) erklärt. Die IPA zu entpacken, um eine Datei zu ändern, und sie dann wieder zu packen, bricht dieses Siegel. **Nimm die Änderung in deiner Konfiguration vor und bau dann neu.** Fass die von EAS erzeugte IPA niemals nachträglich an. Dasselbe gilt für Code am falschen Ort, zum Beispiel in einem `.zip`-Archiv: Der App Store kann ihn nicht neu signieren. Apple beschreibt die erlaubten Orte auf seiner Seite über [den Inhalt eines Bundles](https://developer.apple.com/documentation/bundleresources/placing-content-in-a-bundle). ### Lokale Credentials Wenn dein EAS-Profil `"credentialsSource": "local"` nutzt, zeigt deine Datei `credentials.json` auf ein `.p12`-Zertifikat und ein `.mobileprovision`-Profil. Prüf das Profil mit den Befehlen aus Schritt 3: Es muss vom Typ App Store sein und dein aktuelles Distributionszertifikat enthalten. Und halte diese Dateien aus dem Repository heraus, genau wie [die API-Schlüssel einer Expo-App](https://devoria.fr/de/blog/geheimer-api-schluessel-expo-app). ### Wenn alles gültig ist Bleibt ein frustrierender Fall. Im Apple-Forum sehen Entwickler, wie der Fehler verschwindet, wenn sie denselben Build ohne Änderung noch einmal schicken. Im August und September 2026 beschreiben zwei Threads das Gegenteil: neues Zertifikat und neues Profil, Signatur geprüft, und der Fehler bleibt. In einem davon rät ein Apple-Ingenieur zu einem Bug-Report mit der IPA, der Signaturanalyse und den Transporter-Logs und danach zu einem Kontakt mit App Store Connect. Schick also einmal neu, mit einer neuen Build-Nummer. Kommt der Fehler wieder, obwohl deine vier Befehle sauber sind, melde ihn Apple mit diesen Infos. **Widerruf dein Zertifikat nicht reflexartig**: Das löst nichts zusätzlich und macht deine Profile ungültig. ## Deinen Build ohne böse Überraschung hochladen Eine Signatur prüfst du in zwei Minuten vor dem Upload. Die anderen automatischen Prüfungen verlangen dieselbe Sorgfalt, etwa [ITMS-90725](https://devoria.fr/de/blog/itms-90725-sdk-version-issue-expo-beheben) für die Xcode-Version oder [ITMS-90683](https://devoria.fr/de/blog/itms-90683-missing-purpose-string-expo) für die Berechtigungstexte. Den kompletten Weg vom Build bis zum Upload, ohne Mac, findest du in [eine iOS-App ohne Mac veröffentlichen](https://devoria.fr/de/blog/ios-app-ohne-mac-veroeffentlichen-expo-eas). Ablehnungen durch einen Reviewer brauchen mehr Abstand: Das Vorgehen steht auf der Seite [App von Apple abgelehnt](https://devoria.fr/de/expertise/app-von-apple-abgelehnt), die häufigsten Gründe in [warum Apple eine App ablehnt](https://devoria.fr/de/blog/app-store-ablehnung-apple-gruende). Um dein Projekt vor dem Upload zu prüfen, vereint das [Review Kit](https://devoria.fr/de/kits/app-review) meine Checkliste und Claude-Code-Skills, die dein Projekt durchgehen. Wenn dein Upload hängt und du einen menschlichen Blick willst, [buch eine Stunde mit mir](https://devoria.fr/de/coaching): Wir gehen dein Projekt per Video auf deinem Bildschirm durch. Und wenn du deinen ersten Release vorbereitest, [mach deine kostenlose Diagnose](https://devoria.fr/de/diagnostic): Sie bringt die Schritte in die richtige Reihenfolge und schickt dir meine Checkliste gegen Apple-Ablehnungen. ## Häufige Fragen ### Ist ITMS-90034 eine Ablehnung durch App Review? Nein. Es ist eine automatische Validierung beim Upload des Builds, vor TestFlight und vor jedem Review. Niemand hat deine App geöffnet: Apple hat nur festgestellt, dass ihre Signatur nicht von einem gültigen Distributionszertifikat stammt. ### Muss ich mein Distributionszertifikat widerrufen, um ITMS-90034 zu beheben? Nur wenn es kompromittiert oder schon ungültig ist. Ein funktionierendes Zertifikat zu widerrufen macht deine Profile ungültig, ohne die Ursache zu beheben. Lies zuerst die Signatur deiner IPA mit `codesign` und behebe dann, worauf der Entscheidungsbaum zeigt. ### Kann man ITMS-90034 mit einem Remote-Update beheben? Nein. Die Signatur ist Teil des Binarys, und der abgelehnte Build wird nie nutzbar sein. Du musst ein neues, korrekt signiertes Binary erstellen und es neu hochladen. ### Warum nennt der Fehler mein Widget und nicht meine App? Weil das Widget ein eigenes Bundle ist, mit eigenem Profil signiert. Ist es EAS nicht bekannt oder wurde es anders signiert, lässt es den ganzen Upload scheitern. Deklarier die Extension in deiner Konfiguration und bau neu. ### Was tun, wenn codesign sagt, dass alles gültig ist? Prüf auch das eingebettete Profil und jede Extension. Ist alles sauber, schick einmal neu mit einer neuen Build-Nummer. Bleibt der Fehler, schick Apple einen Report mit der IPA, der Ausgabe von `codesign` und den Upload-Logs. ## Dein Projekt [Review Kit](https://devoria.fr/de/kits/app-review): Meine Checkliste für die App Store Review, meine von Apple abgelehnten und korrigierten Fälle, die für Google Play und drei Claude Code Skills. 49 €. [iOS & Android Kit](https://devoria.fr/de/kits/ios): Bau deine iPhone- und Android-App mit Claude Code: der Startcode meiner Apps, der Weg bis in die Stores und alle Kits. 99 €. [Diagnose: Was dich von deiner iPhone-App trennt](https://devoria.fr/de/diagnostic): 7 Fragen, 60 Sekunden: Du erfährst, was dich wirklich davon abhält, deine iPhone-App zu veröffentlichen, bekommst deinen Weg in 4 Schritten und das passende Kit.