# ITMS-90034: Missing or invalid signature -virheen korjaus > ITMS-90034: buildiäsi ei ole allekirjoitettu voimassa olevalla jakeluvarmenteella. Tarkista allekirjoitus codesignilla ja tee uusi store-build EAS:llä. Alkuperäinen sivu: [ITMS-90034: Missing or invalid signature -virheen korjaus](https://devoria.fr/fi/blog/itms-90034-missing-or-invalid-signature-korjaus) Kirjoittaja: [Mehdi Azizi](https://devoria.fr/fi/mehdi-azizi) Julkaistu: 2026-11-04 Sisältö tarkistettu viimeksi: 2026-11-04 ITMS-90034 tulee vastaan, kun lähetät buildin App Store Connectiin. Virhe kertoo, että sovellustasi tai jotain sen osaa ei ole allekirjoitettu Applen lähetysvarmenteella eli voimassa olevalla jakeluvarmenteella. **Korjaus: selvitä, mikä bundle on allekirjoitettu väärin ja miksi, ja tee sitten uusi App Storea varten allekirjoitettu build.** Tämä opas keskittyy pelkkään virheeseen. Jos sanat varmenne ja profiili ovat sinulle epäselviä, lue ensin [iOS-kehittäjävarmenne ja provisioning profile](https://devoria.fr/fi/blog/ios-kehittajavarmenne-provisioning-profile-expo). Täältä löydät luettavan viestin, päätöspuun, komennot IPA:n tutkimiseen ja korjauksen EAS:n hallinnoimilla tunnuksilla. EAS-osuutta varten luin EAS CLI 24.10.0:n koodin, joka valitsee varmenteen. ## Mitä virhe ITMS-90034 tarkoittaa? Tässä sen tavallinen muoto esimerkkinimillä: > 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. Vuonna 2026 se näkyy Applen foorumilla myös muodossa "Validation failed (409) Missing or invalid signature", jota seuraa sama teksti ja "(ID: 90034)". "Lähetysvarmenne" on jakeluvarmenne. [Applen varmenneohje](https://developer.apple.com/help/account/certificates/certificates-overview) sanoo sen suoraan: kehitysvarmenteilla ajat sovellusta omilla laitteillasi, jakeluvarmenteilla jaat sen tai lähetät sen App Store Connectiin. **Lue viestissä mainittu polku: se osoittaa vialliseen bundleen.** `Payload/MyApp.app` tarkoittaa itse sovellusta. Polku, joka päättyy `.appex`, tarkoittaa laajennusta, kuten widgetiä. Polku, joka päättyy `.framework`, tarkoittaa mukana olevaa kirjastoa. Kyse ei ole reviewerin hylkäyksestä. Validointi kaatuu lähetyksessä tai buildin käsittelyn aikana, ennen TestFlightia: tämä build ei koskaan päädy testaajillesi. ## Päätöspuu: viestistä korjaukseen Jokainen rivi vastaa vihjettä, jonka luet viestistä, seuraavan osion komennoista tai EAS:n lokeista. Käy ne läpi järjestyksessä: ensimmäinen osuva rivi näyttää suunnan. | Mitä havaitset | Todennäköinen syy | Korjaus | | --------------------------- | --------------------------- | ------------------------- | | Polku päättyy `.appex` | Laajennus väärin allekirj. | Ilmoita laajennus | | `Signature=adhoc` | Allekirjoittamaton build | Build store-profiililla | | `Apple Development` | Kehitysbuild | Build store-profiililla | | `ProvisionedDevices` löytyy | Sisäinen build (ad hoc) | Build store-profiililla | | `sealed resource` | IPA:ta muokattu jälkikäteen | Tee build uudelleen | | EAS: "no longer valid" | Varmenne mitätöity | Uusi varmenne | | Kaikki on kunnossa | Häiriö Applen päässä | Lähetä uudelleen, ilmoita | ## Tutki IPA:si neljällä komennolla Lataa IPA buildin sivulta expo.devissä ja avaa pääte Macillasi. **1. Kuka allekirjoitti sovelluksen?** ```bash unzip -q MyApp.ipa -d ipa codesign -dv --verbose=4 ipa/Payload/*.app 2>&1 | grep -E "^(Identifier|Authority|Signature|TeamIdentifier)=" ``` `codesign` kirjoittaa virhetulosteeseen, siksi `2>&1`. [Applen teknisen muistion TN3161](https://developer.apple.com/documentation/technotes/tn3161-inside-code-signing-certificates) mukaan jokainen `Authority`-rivi on luottamusketjun lenkki. Ensimmäisen pitää alkaa `Apple Distribution:` tai `iPhone Distribution:` ja jatkua tiimisi nimellä. Jälkimmäinen on vanhan iOS Distribution -tyypin nimi: koodinsa perusteella EAS CLI 24.10.0 luo yhä tämän tyypin varmenteita. Jos näet `Apple Development:`, kyseessä on kehitysbuild. Jos näet `Signature=adhoc` ilman yhtään `Authority`-riviä, binääriä ei ole allekirjoitettu millään varmenteella. **2. Onko sovellusta muokattu allekirjoituksen jälkeen?** ```bash codesign --verify --deep --strict -vv ipa/Payload/*.app ``` Haluat nähdä `valid on disk` ja sen jälkeen `satisfies its Designated Requirement`. TN3161 kertoo, mitä tarkistus takaa: kaikki odotetut tiedostot ovat paikallaan, yhtään ei ole lisätty eikä yhtään muokattu. Testibundlessa, jonka allekirjoitin ja sitten muokkasin, komento vastasi `a sealed resource is missing or invalid` ja sen jälkeen `file modified:` sekä muutetun tiedoston. Valitsin `--deep` on tässä tarkistusta varten, ei koskaan allekirjoitusta: Applen foorumilla tukitiimin insinööri neuvoo olemaan käyttämättä sitä allekirjoittamiseen. **3. Mikä profiili on mukana?** ```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 ``` Nämä ovat [profiileja käsittelevän muistion TN3125](https://developer.apple.com/documentation/technotes/tn3125-inside-code-signing-provisioning-profiles) komennot. App Store -profiilissa ei ole laiteluetteloa: toisen rivin pitää vastata `Could not extract value`. Jos se näyttää laitetunnisteita, kyseessä on ad hoc -profiili eli sisäisen buildin profiili. Kolmas rivi kertoo profiilin vanhenemispäivän. **4. Onko laajennukset ja frameworkit allekirjoitettu samalla tavalla?** ```bash find ipa/Payload/*.app \( -name "*.appex" -o -name "*.framework" \) \ -exec sh -c 'echo "$1"; codesign -dvv "$1" 2>&1 | grep -m1 "^Authority="' _ {} \; ``` Jokaisen osan pitää näyttää sama `Authority`-rivi kuin sovelluksen. Jos jokin poikkeaa, viesti mainitsee juuri sen. Jos haluat tarkistaa ennen lähetystä, TN3161 suosittelee `altool`ia, joka tekee saman tarkistuksen kuin Xcoden Validate App -painike. Se vaatii App Store Connect -API-avaimen, jonka tiedosto `AuthKey_.p8` sijoitetaan kansioon `~/.appstoreconnect/private_keys`: ```bash xcrun altool --validate-app -f MyApp.ipa -t ios --api-key --api-issuer ``` ## Korjaa EAS:llä syy kerrallaan ### Sisäinen build tai kehitysbuild lähetetty Applelle [Expon eas.json-dokumentaation](https://docs.expo.dev/build/eas-json/) mukaan buildeja, joissa on `"distribution": "internal"`, ei allekirjoiteta kauppoja varten: ne käyttävät ad hoc -profiilia. Vain `store`-jakelun profiili, joka on oletus, tuottaa lähetyskelpoisen buildin. **Varminta on lähettää juuri rakentamasi build valitsematta sitä käsin**: ```bash eas build --platform ios --profile production --auto-submit ``` Jos käytät `eas submit --path`, tarkista, että tiedosto on varmasti viimeisin store-buildisi. Applen foorumilla eräs tiimi huomasi, että sen lähetystyökalu lähetti joka kerta vanhan, gitiin versioidun IPA:n. ### Unohtunut laajennus Jokainen laajennus on oma bundlensa, jolla on oma tunnisteensa ja oma profiilinsa. Expo-projektissa, jossa natiivikoodi generoidaan, [Expon iOS-laajennussivu](https://docs.expo.dev/build-reference/app-extensions/) neuvoo ilmoittamaan ne kohdassa `extra.eas.build.experimental.ios.appExtensions`. Silloin EAS CLI tuntee ne ennen buildia ja luo tai validoi niiden tunnukset. Useimmat laajennuksen lisäävät kirjastot kirjoittavat tämän määrittelyn puolestasi pluginillaan. Solys, minigameja sisältävä herätyskelloni, sisältää neljä laajennusta: widgetin ja kolme Ruutuaika-laajennusta. Kaikki neljä on ilmoitettu sen konfiguraatiossa, ja EAS:llä on profiili jokaiselle. **Xcodessa käsin lisätty laajennus ilman tätä määrittelyä on ihanteellinen epäilty**, kun viestin polku päättyy `.appex`. ### Mitätöity tai vanhentunut varmenne [Applen varmennesivu](https://developer.apple.com/support/certificates/) on selvä: et voi enää lähettää buildia, joka on allekirjoitettu vanhentuneella tai mitätöidyllä varmenteella. Jo lähetetty mutta vielä arvioon lähettämätön build voi jopa siirtyä tilaan Invalid Binary, jos sen varmenne on mitätöity. EAS CLI 24.10.0:n koodi näyttää, milloin tämä jää huomaamatta: - **Interaktiivinen build, kirjautuneena Appleen**: EAS vertaa varmennettaan Applella yhä voimassa oleviin. Jos sitä ei enää löydy, se näyttää "Current distribution certificate is no longer valid in Apple Dev Portal" ja tarjoaa valita tai luoda uuden. - **Interaktiivinen build ilman kirjautumista**: EAS tarkistaa vain päivämäärät ja varoittaa ohittavansa validoinnin Applella. - **Ei-interaktiivinen build jatkuvassa integraatiossa**: EAS näyttää "Distribution Certificate is not validated for non-interactive builds" ja allekirjoittaa silti. **Jatkuvassa integraatiossa EAS ei tarkista itse varmennetta uudelleen: mitätöinti voi paljastua vasta lähetyksessä.** Korjaus: aja interaktiivinen build kirjautuneena Apple-tilillesi tai käytä komentoa `eas credentials --platform ios`, valikkoa Build Credentials ja sitten "Distribution Certificate: Add a new one to your account". Profiilit, joissa vanha varmenne oli, muuttuvat virheellisiksi: EAS tarkistaa ne seuraavassa buildissa ja tekee ne uudelleen. Applen rajat varmenteiden määrälle on kuvattu [iOS-kehittäjävarmenteen oppaassa](https://devoria.fr/fi/blog/ios-kehittajavarmenne-provisioning-profile-expo). ### Allekirjoituksen jälkeen muokattu binääri Allekirjoitus sinetöi koodin, resurssit ja metatiedot tiivisteillä, kuten [Applen muistio TN3126](https://developer.apple.com/documentation/technotes/tn3126-inside-code-signing-hashes) selittää. Jos purat IPA:n muuttaaksesi tiedostoa ja pakkaat sen uudelleen, sinetti rikkoutuu. **Tee muutos konfiguraatioon ja tee sitten uusi build.** Älä koskaan muokkaa EAS:n tuottamaa IPA:ta. Sama pätee koodiin, joka on väärässä paikassa, esimerkiksi `.zip`-arkistossa: App Store ei voi allekirjoittaa sitä uudelleen. Apple kuvaa sallitut sijainnit sivullaan [bundlen sisällöstä](https://developer.apple.com/documentation/bundleresources/placing-content-in-a-bundle). ### Paikalliset tunnukset Jos EAS-profiilisi käyttää asetusta `"credentialsSource": "local"`, `credentials.json`-tiedostosi osoittaa `.p12`-varmenteeseen ja `.mobileprovision`-profiiliin. Tarkista profiili vaiheen 3 komennoilla: sen pitää olla App Store -tyyppinen ja sisältää nykyinen jakeluvarmenteesi. Ja pidä nämä tiedostot poissa repositoriosta, kuten [Expo-sovelluksen API-avaimet](https://devoria.fr/fi/blog/salainen-api-avain-expo-sovellus). ### Kun kaikki on kunnossa Jäljellä on yksi turhauttava tapaus. Applen foorumilla jotkut kehittäjät näkevät virheen katoavan, kun he lähettävät saman buildin uudelleen muuttamatta mitään. Elo- ja syyskuussa 2026 kaksi ketjua kuvasi päinvastaista: uusi varmenne ja profiili, tarkistettu allekirjoitus, silti jatkuva epäonnistuminen. Toisessa niistä Applen insinööri neuvoi tekemään bugiraportin, jossa on IPA, allekirjoitusanalyysi ja Transporterin lokit, ja ottamaan sitten yhteyttä App Store Connectiin. Lähetä siis kerran uudelleen uudella build-numerolla. Jos virhe palaa, vaikka neljä komentoasi näyttävät puhdasta, ilmoita siitä Applelle näiden tietojen kanssa. **Älä mitätöi varmennettasi refleksinä**: se ei ratkaise mitään ylimääräistä ja tekee profiileistasi virheellisiä. ## Lähetä buildisi ilman ikäviä yllätyksiä Allekirjoituksen tarkistaa kahdessa minuutissa ennen lähetystä. Muut automaattiset tarkistukset vaativat samaa huolellisuutta, kuten [ITMS-90725](https://devoria.fr/fi/blog/itms-90725-sdk-version-issue-expo) Xcoden version osalta tai [ITMS-90683](https://devoria.fr/fi/blog/itms-90683-missing-purpose-string-expo) lupatekstien osalta. Koko polku buildista lähetykseen ilman Macia löytyy oppaasta [iOS-sovelluksen julkaisu ilman Macia](https://devoria.fr/fi/blog/ios-sovellus-julkaisu-ilman-macia-expo-eas). Reviewerin hylkäykset vaativat enemmän harkintaa: toimintatapa on sivulla [Applen hylkäämä sovellus](https://devoria.fr/fi/expertise/apple-hylkasi-sovelluksen), ja yleisimmät syyt artikkelissa [miksi Apple hylkää sovelluksen](https://devoria.fr/fi/blog/apple-hylkasi-sovelluksen-syyt). Jos haluat tarkistaa kokonaisuuden ennen lähetystä, [Review Kit](https://devoria.fr/fi/kits/app-review) sisältää tarkistuslistani ja Claude Code -skillejä, jotka käyvät projektisi läpi. Jos lähetyksesi jumittaa ja haluat ihmisen näkemyksen, [varaa tunti kanssani](https://devoria.fr/fi/coaching): käymme projektisi läpi videopuhelussa, sinun ruudullasi. Ja jos valmistelet ensimmäistä julkaisuasi, [tee ilmainen diagnoosi](https://devoria.fr/fi/diagnostic): se laittaa vaiheet oikeaan järjestykseen ja lähettää sinulle tarkistuslistani Applen hylkäysten välttämiseen. ## Usein kysytyt kysymykset ### Onko ITMS-90034 App Review -hylkäys? Ei. Se on automaattinen validointi, joka tehdään buildin lähetyksessä, ennen TestFlightia ja ennen mitään arviointia. Kukaan ei ole avannut sovellustasi: Apple on vain todennut, ettei sen allekirjoitus tule voimassa olevasta jakeluvarmenteesta. ### Pitääkö jakeluvarmenne mitätöidä ITMS-90034:n korjaamiseksi? Vain jos se on vaarantunut tai jo virheellinen. Toimivan varmenteen mitätöinti tekee profiileistasi virheellisiä korjaamatta syytä. Lue ensin IPA:si allekirjoitus `codesign`-komennolla ja korjaa sitten se, mihin päätöspuu osoittaa. ### Voiko ITMS-90034:n korjata etäpäivityksellä? Ei. Allekirjoitus on osa binääriä, eikä hylättyä buildia voi koskaan käyttää. Sinun pitää tuottaa uusi, oikein allekirjoitettu binääri ja lähettää se uudelleen. ### Miksi virhe mainitsee widgetini eikä sovellustani? Koska widget on oma bundlensa, joka allekirjoitetaan omalla profiilillaan. Jos sitä ei ole ilmoitettu EAS:lle tai se on allekirjoitettu toisin, se kaataa koko lähetyksen. Ilmoita laajennus konfiguraatiossasi ja tee uusi build. ### Mitä teen, jos codesign sanoo kaiken olevan kunnossa? Tarkista myös mukana oleva profiili ja jokainen laajennus. Jos kaikki on puhdasta, lähetä kerran uudelleen uudella build-numerolla. Jos virhe jatkuu, lähetä Applelle raportti, jossa on IPA, `codesign`-komennon tuloste ja lähetyksen lokit. ## Projektisi [Review Kit](https://devoria.fr/fi/kits/app-review): App Store -tarkastuksen tarkistuslistani, korjatut Applen hylkäykseni, Google Playn lista ja kolme Claude Code -skilliä. 49 €. [iOS & Android Kit](https://devoria.fr/fi/kits/ios): Tee iPhone- ja Android-sovelluksesi Claude Codella: sovellusteni pohjakoodi, polku kauppoihin asti ja kaikki kitit. 99 €. [Diagnoosi: mikä erottaa sinut omasta iPhone-sovelluksestasi](https://devoria.fr/fi/diagnostic): 7 kysymystä, 60 sekuntia: tiedät, mikä oikeasti estää sinua julkaisemasta iPhone-sovellustasi, saat 4 vaiheen polkusi ja sinulle sopivan kitin.