# ITMS-90034: come risolvere Missing or invalid signature > ITMS-90034: la tua build non è firmata con un certificato di distribuzione valido. Leggi la firma con codesign, poi rifai una build store con EAS. Pagina originale: [ITMS-90034: come risolvere Missing or invalid signature](https://devoria.fr/it/blog/itms-90034-missing-invalid-signature) Autore: [Mehdi Azizi](https://devoria.fr/it/mehdi-azizi) Pubblicazione: 2026-11-04 Ultima revisione dei contenuti: 2026-11-04 ITMS-90034 compare quando invii la tua build ad App Store Connect. Dice che la tua app, o uno dei suoi componenti, non è firmata con un certificato di invio Apple, cioè con un certificato di distribuzione valido. **La soluzione: capire quale bundle è firmato male e perché, poi rifare una build firmata per l'App Store.** Questa guida resta concentrata sull'errore. Se le parole certificato e profilo non ti sono chiare, leggi prima [certificato sviluppatore iOS e provisioning profile](https://devoria.fr/it/blog/certificato-sviluppatore-ios-provisioning-profile-expo). Qui trovi il messaggio da leggere, un albero decisionale, i comandi che ispezionano la tua IPA e la correzione con le credenziali gestite da EAS. Per la parte EAS ho letto il codice di EAS CLI 24.10.0 che sceglie il certificato. ## Cosa significa l'errore ITMS-90034? Ecco la sua forma classica, con nomi di esempio: > 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. Nel 2026, sul forum di Apple, compare anche nella forma "Validation failed (409) Missing or invalid signature", seguita dallo stesso testo e da "(ID: 90034)". Il "certificato di invio" è il certificato di distribuzione. [La guida di Apple sui certificati](https://developer.apple.com/help/account/certificates/certificates-overview) lo dice chiaramente: i certificati di sviluppo servono a eseguire la tua app sui tuoi dispositivi, quelli di distribuzione a distribuirla o a inviarla ad App Store Connect. **Leggi il percorso citato: indica il bundle colpevole.** `Payload/MyApp.app` si riferisce all'app stessa. Un percorso che finisce con `.appex` si riferisce a un'estensione, come un widget. Un percorso in `.framework` si riferisce a una libreria incorporata. Non è il rifiuto di un reviewer. La validazione scatta all'invio o durante l'elaborazione della build, prima di TestFlight: questa build non arriverà mai ai tuoi tester. ## L'albero decisionale: dal messaggio alla correzione Ogni riga corrisponde a un indizio che leggi nel messaggio, nei comandi della sezione successiva o nei log di EAS. Seguile in ordine: la prima che corrisponde ti dà la pista. | Cosa osservi | Causa probabile | Correzione | | -------------------------- | ----------------------- | ------------------------ | | Percorso in `.appex` | Estensione firmata male | Dichiarare l'estensione | | `Signature=adhoc` | Build non firmata | Build con profilo store | | `Apple Development` | Build di sviluppo | Build con profilo store | | `ProvisionedDevices` letto | Build interna (ad hoc) | Build con profilo store | | `sealed resource` | IPA modificata dopo | Rifare la build | | EAS: "no longer valid" | Certificato revocato | Nuovo certificato | | Tutto è valido | Problema lato Apple | Reinviare, poi segnalare | ## Ispezionare la tua IPA in quattro comandi Scarica l'IPA dalla pagina della build su expo.dev, poi apri un terminale sul tuo Mac. **1. Chi ha firmato l'app?** ```bash unzip -q MyApp.ipa -d ipa codesign -dv --verbose=4 ipa/Payload/*.app 2>&1 | grep -E "^(Identifier|Authority|Signature|TeamIdentifier)=" ``` `codesign` scrive sullo standard error, da qui il `2>&1`. Secondo [la nota tecnica TN3161 di Apple](https://developer.apple.com/documentation/technotes/tn3161-inside-code-signing-certificates), ogni riga `Authority` è un anello della catena di fiducia. La prima deve iniziare con `Apple Distribution:` o `iPhone Distribution:`, seguita dal nome del tuo team. La seconda etichetta è quella del vecchio tipo iOS Distribution: in base al suo codice, EAS CLI 24.10.0 crea ancora certificati di questo tipo. Se leggi `Apple Development:`, è una build di sviluppo. Se leggi `Signature=adhoc` senza nessuna riga `Authority`, il binario non è firmato da alcun certificato. **2. L'app è stata modificata dopo la firma?** ```bash codesign --verify --deep --strict -vv ipa/Payload/*.app ``` Vuoi leggere `valid on disk`, poi `satisfies its Designated Requirement`. TN3161 precisa cosa garantisce questo controllo: tutti i file attesi ci sono, nessuno è stato aggiunto, nessuno è stato modificato. Su un bundle di test che ho firmato e poi ritoccato, il comando risponde `a sealed resource is missing or invalid`, poi `file modified:` seguito dal file cambiato. L'opzione `--deep` qui serve a verificare, mai a firmare: sul forum di Apple, un ingegnere del team di supporto la sconsiglia per la firma. **3. Quale profilo è incorporato?** ```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 ``` Sono i comandi della [nota TN3125 sui profili](https://developer.apple.com/documentation/technotes/tn3125-inside-code-signing-provisioning-profiles). Un profilo App Store non contiene alcuna lista di dispositivi: la seconda riga deve rispondere `Could not extract value`. Se mostra identificativi di dispositivi, è un profilo ad hoc, quello di una build interna. La terza dà la data di scadenza del profilo. **4. Estensioni e framework sono firmati allo stesso modo?** ```bash find ipa/Payload/*.app \( -name "*.appex" -o -name "*.framework" \) \ -exec sh -c 'echo "$1"; codesign -dvv "$1" 2>&1 | grep -m1 "^Authority="' _ {} \; ``` Ogni componente deve mostrare la stessa riga `Authority` dell'app. Se uno se ne discosta, è quello citato dal messaggio. Se vuoi verificare prima dell'invio, TN3161 consiglia `altool`, lo stesso controllo del pulsante Validate App di Xcode. Richiede una chiave API di App Store Connect, il cui file `AuthKey_.p8` va messo in `~/.appstoreconnect/private_keys`: ```bash xcrun altool --validate-app -f MyApp.ipa -t ios --api-key --api-issuer ``` ## Correggere con EAS, causa per causa ### Una build interna o di sviluppo inviata ad Apple Secondo la [documentazione di Expo su eas.json](https://docs.expo.dev/build/eas-json/), le build in `"distribution": "internal"` non sono firmate per gli store: usano un profilo ad hoc. Solo un profilo con distribuzione `store`, il valore predefinito, produce una build inviabile. **La cosa più sicura è inviare la build che hai appena creato, senza sceglierla a mano**: ```bash eas build --platform ios --profile production --auto-submit ``` Se usi `eas submit --path`, controlla che il file sia davvero la tua ultima build store. Sul forum di Apple, un team ha scoperto che il suo strumento di invio rimandava ogni volta una vecchia IPA, versionata in git. ### Un'estensione dimenticata Ogni estensione è un bundle a sé, con il suo identificativo e il suo profilo. In un progetto Expo con generazione nativa, la [pagina di Expo sulle estensioni iOS](https://docs.expo.dev/build-reference/app-extensions/) chiede di dichiararle in `extra.eas.build.experimental.ios.appExtensions`. EAS CLI le conosce così prima della build, e crea o valida le loro credenziali. La maggior parte delle librerie che aggiungono un'estensione scrive questa dichiarazione per te, tramite il proprio plugin. Solys, la mia sveglia con minigiochi, incorpora quattro estensioni: un widget e tre estensioni di Screen Time. Tutte e quattro sono dichiarate nella sua configurazione, ed EAS ha un profilo per ognuna. **Un'estensione aggiunta a mano in Xcode, senza questa dichiarazione, è la candidata ideale** per un percorso in `.appex` nel messaggio. ### Un certificato revocato o scaduto La [pagina di Apple sui certificati](https://developer.apple.com/support/certificates/) è chiara: non puoi più inviare una build firmata con un certificato scaduto o revocato. Una build già inviata ma non ancora sottoposta a revisione può persino passare in Invalid Binary se il suo certificato è stato revocato. Il codice di EAS CLI 24.10.0 mostra quando questo caso passa inosservato: - **Build interattiva, connessa ad Apple**: EAS confronta il suo certificato con quelli ancora validi presso Apple. Se non c'è più, mostra "Current distribution certificate is no longer valid in Apple Dev Portal" e ti propone di sceglierne o crearne uno. - **Build interattiva, senza connessione**: EAS verifica solo le date e avvisa che salta la validazione presso Apple. - **Build non interattiva, in integrazione continua**: EAS mostra "Distribution Certificate is not validated for non-interactive builds" e firma comunque. **In integrazione continua, EAS non ricontrolla il certificato stesso: una revoca può emergere solo all'invio.** La soluzione: lancia una build interattiva connessa al tuo account Apple, oppure usa `eas credentials --platform ios`, menu Build Credentials, poi "Distribution Certificate: Add a new one to your account". I profili che contenevano il vecchio certificato diventano non validi: EAS li controlla alla build successiva e li rigenera. I limiti di Apple sul numero di certificati sono spiegati nella [guida sul certificato sviluppatore iOS](https://devoria.fr/it/blog/certificato-sviluppatore-ios-provisioning-profile-expo). ### Un binario modificato dopo la firma La firma sigilla codice, risorse e metadati tramite hash, come spiega [la nota TN3126 di Apple](https://developer.apple.com/documentation/technotes/tn3126-inside-code-signing-hashes). Decomprimere l'IPA per cambiare un file e poi ricomprimerla rompe questo sigillo. **Fai la modifica nella tua configurazione, poi rifai la build.** Non ritoccare mai l'IPA prodotta da EAS. Stessa logica per il codice messo nel posto sbagliato, per esempio in un archivio `.zip`: l'App Store non può rifirmarlo. Apple descrive le posizioni consentite nella sua pagina su [il contenuto di un bundle](https://developer.apple.com/documentation/bundleresources/placing-content-in-a-bundle). ### Credenziali locali Se il tuo profilo EAS usa `"credentialsSource": "local"`, il tuo file `credentials.json` punta a un certificato `.p12` e a un profilo `.mobileprovision`. Controlla il profilo con i comandi del passo 3: deve essere di tipo App Store e contenere il tuo certificato di distribuzione attuale. E tieni questi file fuori dal repository, come [le chiavi API di un'app Expo](https://devoria.fr/it/blog/chiave-api-segreta-app-expo). ### Quando tutto è valido Resta un caso frustrante. Sul forum di Apple, alcuni sviluppatori vedono l'errore sparire reinviando la stessa build, senza cambiare nulla. Ad agosto e settembre 2026, due thread descrivono il contrario: certificato e profilo nuovi, firma verificata, errore persistente. In uno dei due, un ingegnere di Apple consiglia una segnalazione di bug con l'IPA, l'analisi della firma e i log di Transporter, poi un contatto con App Store Connect. Quindi reinvia una volta con un nuovo numero di build. Se l'errore torna anche se i tuoi quattro comandi sono puliti, segnalalo ad Apple con questi elementi. **Non revocare il certificato per riflesso**: non risolve nulla in più e invalida i tuoi profili. ## Inviare la tua build senza brutte sorprese Una firma si verifica in due minuti prima dell'invio. Gli altri controlli automatici richiedono lo stesso rigore, come [ITMS-90725](https://devoria.fr/it/blog/itms-90725-sdk-version-issue-expo) per la versione di Xcode o [ITMS-90683](https://devoria.fr/it/blog/itms-90683-missing-purpose-string-expo) per le frasi di autorizzazione. Il percorso completo dalla build all'invio, senza Mac, è in [pubblicare un'app iOS senza Mac](https://devoria.fr/it/blog/pubblicare-app-ios-senza-mac-expo-eas). I rifiuti di un reviewer richiedono più distacco: il procedimento è nella pagina [app rifiutata da Apple](https://devoria.fr/it/expertise/app-rifiutata-da-apple), e i motivi più frequenti sono in [perché Apple rifiuta un'app](https://devoria.fr/it/blog/app-rifiutata-da-apple-perche-casi-reali). Per controllare tutto prima dell'invio, il [Review Kit](https://devoria.fr/it/kits/app-review) riunisce la mia checklist e delle skill di Claude Code che rileggono il tuo progetto. Se il tuo invio è bloccato e vuoi uno sguardo umano, [prenota un'ora con me](https://devoria.fr/it/coaching): riprendiamo il tuo progetto in videochiamata, sul tuo schermo. E se stai preparando la tua prima uscita, [fai la tua diagnosi gratuita](https://devoria.fr/it/diagnostic): rimette i passaggi in ordine e ti invia la mia checklist anti-rifiuto Apple. ## Domande frequenti ### ITMS-90034 è un rifiuto di App Review? No. È una validazione automatica fatta all'invio della build, prima di TestFlight e prima di qualsiasi revisione. Nessuno ha aperto la tua app: Apple ha solo constatato che la sua firma non proviene da un certificato di distribuzione valido. ### Devo revocare il mio certificato di distribuzione per risolvere ITMS-90034? Solo se è compromesso o già non valido. Revocare un certificato che funziona invalida i tuoi profili senza correggere la causa. Inizia leggendo la firma della tua IPA con `codesign`, poi correggi ciò che indica l'albero decisionale. ### Si può risolvere ITMS-90034 con un aggiornamento da remoto? No. La firma fa parte del binario, e la build rifiutata non sarà mai utilizzabile. Devi produrre un nuovo binario firmato correttamente e reinviarlo. ### Perché l'errore cita il mio widget e non la mia app? Perché il widget è un bundle a sé, firmato con il proprio profilo. Se non è dichiarato a EAS o è stato firmato in altro modo, fa fallire l'intero invio. Dichiara l'estensione nella tua configurazione e rifai la build. ### Cosa fare se codesign dice che è tutto valido? Controlla anche il profilo incorporato e ogni estensione. Se è tutto pulito, reinvia una volta con un nuovo numero di build. Se l'errore persiste, invia una segnalazione ad Apple con l'IPA, l'output di `codesign` e i log di invio. ## Il tuo progetto [Review Kit](https://devoria.fr/it/kits/app-review): La mia checklist per la review dell'App Store, i rifiuti di Apple che ho risolto, quella di Google Play e tre skill per Claude Code. 49 €. [iOS & Android Kit](https://devoria.fr/it/kits/ios): Crea la tua app iPhone e Android con Claude Code: il codice di partenza delle mie app, il percorso fino agli store e tutti i kit. 99 €. [Diagnosi: cosa ti separa dalla tua app per iPhone](https://devoria.fr/it/diagnostic): 7 domande, 60 secondi: scopri cosa ti blocca davvero nel pubblicare la tua app per iPhone, il tuo percorso in 4 tappe e il kit giusto per te.