I wondering if any of you might be able to point me in the right direction on this. I'm likewise having issues trying to submit an ipa file to iTunes Connect via Application Loader, and got as far as zipping the .app file and submitting. I get an error in Application Loader that: "Unable to run the lipo command: ... Can't map input file ..." and "Application failed codesign verification. The signature was invalid, contains disallowed entitlements, or was not signed with an iPhone Distribution Certificate.", and "Unable to extract codesigning entitlements from your application. Please make sure ... is a valid Mach executable that's properly codesigned".
Now, before posting here, I have done the following to no avail:
a) I've regenerated all certs and mobile provisions from the top, completely on the Mac once, and completely on Windows as well using openSSL. Both times, I started at the top, from the csr request.
b) I'm able to install and run my ipa file just fine on the test iPhones using the distribution.p12 file and the associated ad_hoc distribution mobile provision. It's always only when I compile for 'app store release', using the distribution.p12 file and the app_store mobile provision that this happens.
c) I'm using Adobe Flash Pro CS6 on Windows 7 64, with Adobe Air 3.3 SDK, and I am submitting on a real Macbook Air with OS X Mountain Lion.
d) I've also gone as far as trying both sets of cert/provisions (generated on mac and windows), by publishing the ipa from within Flash Pro CS6, and also using the adt command line, but still same.. works fine as ad_hoc on the test iPhones, but will not submit through Application Loader. Same codesign verification errors.
e) My app uses native extensions, but these compile and run perfectly fine on the ad_hoc builds.
I'm pulling out my hair at this point as to what I could possibly be missing or doing wrong, or if there is a bona fide bug with the combination of technologies I'm using? I would appreciate any tips/hints/suggestions from anyone who know what I am describing here.
If there is anyone at Adobe that can look at my ipa file build for the app_store submission, that would be wonderful as well.
with kind regards,
Do you have the WWDC certificate installed?
When you generated your distribution certificate from the portal did you do it before or after you made the app id in the portal? App IDs are assigned to certificates, which makes me crazy. If I create a new app ID I need to re-download the new distribution certificate and re-generate a new .p12 or the app ID (com.example.whateverApp, etc) won't be valid.
If the latter was the issue you would also have ad-hoc issues, unless you downloaded your development certificate at a later time than distribution.
For a company that pureports simplicity as it's overall goal in life, the provisioning portal is an utter failure.
I simply make sure I follow these steps when I make a new app:
1. Make a new App ID
2. Download new certs to generate new dev/dist .p12s (I use a mac for it, keychain access, which generated the original codesign request)
3. Add devices if needed (ad-hoc dev testing)
4. Generate dev/dist mobileprovision for app ticking off all proper testing devices for dev (certificate should be auto-assigned to both)
It's not hard once you've done it a ton of times but anything out of order will upset Apple. Then you must absolutely make sure your apps ID conforms to the way you set your app ID up. Remember, don't put the first portion of the app id like SG93AX29Z1.com.example.*, drop the SG93AX29Z1 portion and make sure your app id is set to "com.example.someThingHere". Otherwise you'll fail codesign on both ad-hoc and store.
Don't forget the new 1024px icon you need to supply too..
Thank you for your suggestions. Yes, I'm on page with you about not liking having to regenerate the certs and mobile provision files after adding a new appID, devices, etc. My problem still remains though: I can compile and run the ipa using the distribution cert and distribution adhoc mobile provision just fine on my iPhone, but when I compile for app store submission using the same distribution cert (and the app store mobile provision for it), when I load it using Application Loader (and I'm using v2.7 on Mountain Lion on my Macbook Air), I get first, that the .ipa or .zip is not a valid archive. So I did as some suggest, rename it as a zip, unzip it, and then re-zip the .app file within the Payload folder, and try submitting that. When I do, that's when I get the code sign validation errors I listed in the first paragraph.
Some more things I've also done since my above post----
a) I've tried to build for app store using AIR 3.4 SDK using Flash Pro CS6, but same thing.
b) I've also tried building from adt command line with AIR 3.4 SDK, same thing.
c) I've tried command line adt build on the Mac itself with AIR 3.4 SDK, same thing.
d) On all of the above scenarios, if compiled for the ad_hoc mobile provision, and loaded on my iPhone through iTunes, it runs fine. So it seems to me, that somehow the application is not getting signed properly for whatever reason.
I'm about out of options and really would appreciate some folks from Adobe giving us some pointers on this....
thank you again,
Can you share your adt compile line? For example when I submit an iPad app I use:
adt -package -target ipa-app-store -storetype pkcs12 -keystore dist-cert.p12 -provisioning-profile dist.mobileprovision MyAppName.ipa MyAppName-app.xml -extdir extensionsDir MyAppName.swf dat AppIconsForPublish Default-Landscape.png iTunesArtwork iTunesArtwork@2x
Everything after MyAppName.swf being folders or files. That includes some ANEs. I also let it default to IOS4 (it's complaining about not suppling min OS version). I enter my password, IPA generates and my apps get accepted just fine.
Between the MyAppName-app.xml app ID, your app ID on the portal or cert there's definitely something that's simply not meshing. I don't do the "unzip, grab Payload/MyAppName.app and rename to IPA" thing.
My adt line looks almost exactly the same as yours. I likewise use native extensions and mine looks like:
adt -package -target ipa-app-store -storetype pkcs12 -keystore distribuion.p12 -provisioning-profile distribution_appstore.mobileprovision myappname.ipa myappname-app.xml -extdir C:\extensiondir myappname.swf iconsfolder Default@2x.png
What version Air SDK are you using? And do you use Flash Pro, Flash Builder, etc. for building writing the app itself? One thing that piqued my curiosity, what do you mean by "I also let it default to iOS4"? How do you do that... =)
thank you again,
I use AIR SDK v3.4. After 3.3 the adt command line utility now warns me I haven't chosen a minimum OS version and auto-assigns iOS 4 as the minimum.
I use Flash Builder to code, Flash Pro if I want to make some quick graphics/animations and export those via SWC into Flash Builder. Only problem with Flash Builder is it still cannot export ANEs without getting hung up on any errors. I can't believe they didn't fix it but I continually check help->updates and it never has a patch. Therefore I must use the command line. There's even an "Ignore Errors" checkbox but it still hangs during export.
I tell Flash Builder to Export Release Build, pick a folder, fill out the usual credentials and inclusions and let it run. It builds a bin-release-temp folder containing everything necessary to build the IPA. I run the adt command line in that folder and it builds the IPA for me.
Thanks again. Maybe I should look into switching to Flash Builder already. I've been in my Flash Pro comfort zone (I'm much more articulate with AS3 than Flex).. I did, however, find this in the 'known issues' release notes for Air 3.4: "[iOS] On some content, Installing an .ipa file with AIR 3.4 occasionally fails with Installation Error: PackageExtractionFailed(3220974)" http://helpx.adobe.com/en/flash-player/release-note/fp_114_air_34_rele ase_notes.html#known_issues
Hoping this isn't what I'm experiencing through it sounds a lot like it. Specifically, I'm seeing 'code sign validation errors' when I try to submit to iTunes Connect using Application Loader... what to do... sigh...
You can make pure ActionScript projects in Flash Builder as well, Flex is optional. I've done 90% AS3 projects. A note on that is, you either use Flex or go all ActionScript. There is no usable bridge between them. While the language for Flex scripting is AS3, you can't simply start an ActionScript project and try to use Flex components. It must be a Flex project to really use them.
Once you try Flex, you'll probably actually like it. I code a bit of c#.NET and it's pretty similar. I also do Xcode/obj-c and it's like that to (although not at all syntactically). I mean in a drag-and-drop component, WYSIWYG kind of way. The XML-esque way you create things is very efficient as well.
Main reason I grabbed FB was built-in ANE support (CS6 added that later) and the code IDE has excellent completion, decent refactoring, a great debugger and memory profiling to find those nasty memory leaks.
That aside, I read that error a bit differently. It seems like an error you'd get after downloading an app from the app store and it fails to install on your device. Your error is the app store itself can't read your package. But who knows.
Wish I could help more but I haven't seen this issue unfortunately.
Do you know if I can simply take my entire .fla project file, import it into Flash Builder, and compile the ipa? It's entirely in AS3, no flex, as you say. Just curious to see if that may be a solution...
I'm posting this so others with the same problem may benefit. This makes no sense at all, but when I changed the ipa file extension to .zip on my Windows machine first (not on the Mac), transferred the .zip file to my Mac, then unzipped it on my Mac, and re-zipped the .app file on the Mac, Application Loader accepted the submission.
I was previously sending the .ipa itself to my Mac, and renaming the file to a .zip file on the Mac as the first step. This is literally the only difference, and it would have saved me 3 days of wasted time.
hope this helps,
Mac must treat .zip differently when it un/compresses? Not sure but glad you got that solved.
On the Flash Builder question, no there's no real "Auto-import" from Flash Pro to Flash Builder. The workflow is very different.
The single thing you lose is the documents main timeline. If you animated things along that timeline you need to embed everything you did on the FLAs main timeline into its own MovieClip. When you export from Flash to use in Flash Builder, you typically export a SWC. When you import that SWC you access library items the same way you do in Flash Pro via code:
var someLibraryObject:MyClass = new MyClass(); // grabbed a library item with the AS linkage ID "MyClass"
This is why you don't want to use the documents main timeline A SWC won't contain that timeline, just library elements. Now technically you don't have to stay away from the main timeline, you could export a SWF of your main timeline and load that, but this is a bunny trail of possible failures all over the place.
Grab the trial and you'll see the workflow is much more code-centric. You get used to thinking of Flash Pro as an application that lets you quickly create complex objects and animations inside MovieClips and Sprites, but then you import them into Flash Builder and utilize them strictly with code.
And of course the whole other side of Flash Builder, besides top notch refactoring, code completion and profiling, is Flex/MXML. That is an entirely different beast. It's really what it is designed for.
MXML is a very simple markup language that makes it a cinch to create AS3 objects. For example to make a new Arial TextField that's bold at x position 100, y position 200, width 300, height 26, font size 24 with the text Hello World, here's the difference:
var tf:TextField = new TextField();
tf.x = 100;
tf.y = 200;
tf.height = 26;
tf.width = 300;
var fmt:TextFormat = new TextFormat();
fmt.font = "Arial";
fmt.size = 24;
fmt.bold = true;
tf.text = "Hello World";
<s:Label text="Hello World" fontFamily="Arial" fontWeight="bold" fontSize="24" x="100" y="200" width="300" height="26"/>
It waters down a bunch of lines of code into a simple to understand markup language. It also has a lot of premade mobile-optimized (hence the s: spark namespace on "<s:Label") components that are drag and drop. More importantly there's a pretty good layout system built into flex. It becomes important so your interfaces can expand and collapse from device to device in an intelligent way.
Almost exact problem here. I was using Flash Builder and everything seemed to work fine with development certifications but when uploading the release version with Aplication Loader it gave me the same errors saying that the file wasn't correctly signed.
In my case the solution was to transfer the file from Windows to Mac using a pendrive instead of through email which was what I was doing before. I'm not sure what exactly happened, but it seems that the process of uploading/downloading through email changed the file in some way.
May be someone who uses Macs and Windows rutinely can explain me why this strange thing happened.
Seems like you and I both had something in common with the process: email. I was likewise, sending myself my app-store release .ipa file via gmail to myself to submit through my Macbook Air. When I changed the file extension to .zip on Windows before I sent it to myself, it worked fine. It worked for you, as you say, when you transfered using your pen drive. Seems like in some cases, sending the .ipa file via email attachment does something to the archive when it's downloaded on the Mac!
hope this helps anyone else who encounters the same,
While pictures and maybe even a small phone video is a decent idea for passing files via e-mail, the e-mail client and server must encode your files contents. Typically if compression headers are detected it will also uncompress and run a quick virus check on it as well.
You can always use a free https://www.dropbox.com/ to transfer files between, well, anything. Computers, devices, etc.
I've got the exact same problem. It's now 02/11/2012 and this issue seems to be persistent.
"Application failed codesign verification. The signature was invalid, contains disallowed entitlements, or was not signed with an iPhone Distribution Certificate."
the original app was built with Flash Pro 5.5 and the Air SDK etc, and works fine. It's in the app store.
So I have loaded up CS6, AIR 4.5 and the Flex libraries etc (combined package) and it all compiles fine and works on the iPhone no problems.
However - try and upload it to the app store - and there comes the problem.
Now - to confuse the issue a bit, there is another problem with CS6, that MAY be causing errors.
The application's xml file contains lines at the top like this.
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<!-- To localize the description, use the following format for the description element.<description><text xml:lang="en">English App description goes here</text><text xml:lang="fr">French App description goes here</text><text xml:lang="ja">Japanese App description goes here</text></description>-->
<text xml:lang="en">Pin Point Premium</text>
<!-- To localize the name, use the following format for the name element.<name><text xml:lang="en">English App name goes here</text><text xml:lang="fr">French App name goes here</text><text xml:lang="ja">Japanese App name goes here</text></name>-->
Now, you can't enter text into the Application Name field in the Publish Details popup.
If I do not wrap the name tag in the <text .... thing, the Geolocation service on the iPhone is seen as inactive. and of course doesn't work.
That is. If I leave it like this, so that it shows up in the Publish Settings,
Pin Point Premium
This breaks the Geolocation service.
Is this breaking the Loader? Who knows.
I don't see anyone actually adressing this issue. Lots of people fiddling at the edges - but no definitive fix.
I'll chime in that I updated to the new localized version of <name> and it disabled my ability to edit it in the publish panel in CS5.5. However I can simply open the XML and edit it so I don't see that as a big deal. Localize everything they suggest and also set your supported languages.
Also make sure you're exporting with distribution, development, to the store.
The interesting thing about the localization in CS6, is that if you don't do it - it breaks the Geolocation API, and any app that uses it. And it breaks it silently. You don't know until you run your app. You then notice of course that your app can no longer get Geolocation data from the iPhone/iPad etc.
Also checked the distribution/development situation. Not this time. I continue the hunt for a solution to this.
It's probably not as much of a CS6 thing than it is AIR3.4. AIR updates the .xml schema here and there and one of the updates was the addition for language support. That changed happened a long time ago.
Many things broke on my app until I used the localized languages schema, most importantly to me being the actual name you see (which makes sense but nonetheless I had no warning either). It started using the name of the SWF exporting rather than the <name> element.
If you have the ability, definitely hold on to older OS installs. When iOS6 hit I had an old Ad-Hoc only app go absolutely nuts. I believe it was created with AIR3.2 or 3.3. Either way it wasn't compatible at all with iOS6 but worked perfectly with iOS5.
I test on 7 iPads of varying hardware and OS versions and from a lot of testing I can tell you update AIR ASAP if possible. It's an Adobe-specific thing. None of my native Xcode/obj-c apps tend to break. I do update them anyhow but as a general rule, update to the latest AIR and inspect the new schema every time for differences.
Just double clicking on a .cer file will install it on either Windows or Mac (after you agreeing to install it). It's found in Keychain on Mac and use certmgr on Windows (found under Other People->Certificates).
I,ve followed the sequence you adviced: AppID, obtain dev/distr .cer files,
then, as you mentioned using Keychain Access to generate the .p12 certificates,
I used that program, the developer and distribution .cer files were easily obtained.
(osx mountain lion).
However, the certificates only appear in the "Certificates" section of Keychain Access,
not in the "My Certificates" section.
When I right-click on them to select "export", the .p12 export option is grayed out.
Next link was not helpful, because the certificates don't appear in the "My Certificates"
Do you have any idea on what I should do?
I already tried the alternative openssl route - but using the AppLoader that resulted in the "Application failed codesign verification.
The signature was invalid, contains disallowed entitlements, or it was not signed with an iPhone Distribution Certificate."
Trying all ways suggested above to pass the ipa (rename to zip on windows side or not, use dropbox or usb key,unzip, rezip on mac) - all the same result.
Flash Pro CS5.5 was used used to generate the ipa. Builds using the developer certificate were succesfully tested on devices - only uploading of build with distribution certificate fails. All .cer files were added to KeyChain before trying the upload.
This past week, I also had the same problem appear again, but this time, the steps that let me properly code sign and submit to iTunes didn't work. I was pulling my hair out and about to smash my Macbook Air when I noticed, while doing the unzip, and zip (the .app file) routine, that I saw a bunch of folders flash by that I recognized should not be part of the app. This particular app I created used both the Milkmangames' goViral ane as well as another by darkredz for his uiwebview ane. Since I ran into the ld duplicate symbols error trying to compile on my Flash Pro CS6, I was using the adt command line with the -hideAneLibSymbols flag. Anyway, to put a long story short, the -extdir folder I was using for this app had a bunch of other files (i.e. php and jquery stuff for the website, etc.) and somehow, when compiled for app store submission, it failed code sign... *even though* the adhoc one compiled perfectly fine and ran on all the test iOS devices.
I ended up creating fresh directories with just the files needed for the compilation, renamed the .ipa file to .zip on my Windows 7 machine, transferred to my Macbook Air, unzipped it there, then zipped the .app file in the Application Payload, and voila, it went through fine this time. Moral of the story: it may be something totally unrelated to anything logical with the programming aspects... all these little undocumented little 'gotcha's... sigh.. =)
hope it helps,
Thanks Alex, that gives an other angle of attack.
Perhaps you could give me next few details (to reduce the amount of try-cases for me)-
1. Did you create the p12 files on windows entirely using openssl? Or using KeyChain only?
2. Just to be 100% sure regarding the zipping process, is this what you did ?
a. on the mac, inside finder, find the zip, right click on it->uncompress.
b. the result is a directory called payload.
c. zip that directory, again inside finder, richt click the dir ->compress. result: payload.zip.
d. is there no need to rename this zip to the original zip name (that was not payload in the first place)?
e. startup ApplicationLoader and select that zip for upload. (or should I somehow "zip the .app file in ApplicationLoader" ? how exactly?)
In my case, I created the certificates using openssl on the windows machine and entered them in KeyChain.
For the generation of the certificates I used a key that was genereated on the windows machine as well.
However, KeyChain lists the presence of a key as well, for which I don't know how it got there
(probably it got generated during a tryal where I tried to use KeyChain to generate the .p12.)
I was wondering, perhaps the fact that the key that was used to generated the .p12 on windows
is another key than the one installed on keychain might give the error message.
My third question thus becomes (only if you were using openssl on windows):
3. What did you do with the key after generating the .p12 files?
Many thanks in advance,
At the last attempt, the distribution certificate has appeared in the "My Certificates" section of KeyChain
after all, enabling it to be exported as .p12 file from KeyChain.
Probably it was because of applying:
1. For keychain:
"In the Preferences dialog box, click Certificates. Then set Online Certificate Status Protocol and Certificate Revocation List to Off. Close the dialog box."
2. I generated the CSR via the context menu from right-clicking my private key.(request a certificate from a certificate authority with "Marius Versteegen")
3. Select "My Certificates" in KeyChain, and then import items -> select downloaded certificate. (instead of double clicking)
So, that's nice. Unfortunately, keeping the certificate generation stuff entirely on the mac side like this, and refraining from
using openssl did not remove the code sign failure during the submission, so the hypothesis that it was caused by using a different key in openssl
than the one in KeyChain is "a busted myth" now.
Yes, this is crazy really. I can't believe this is so unnecessarily difficult. Apple charging $99 a year for the pleasure of sheer frustration....
No matter what I do now, I can not get past the Codesign Failure error.
Is this because of something in CS6? Something Apple has done? no one knows, because this discussion is not only here, but also all over the Apple forums.
I can say, I have actually got 4 apps in the store. Built right up to CS5.5, and uploaded with Apples. ApplicationLoader on a Mac.
The moment I upgraded to CS6, and the new Air skd's etc, I first of all ran into the naming problem with the localization thing, then getting past that got to the CodeSiging error - where I am now stuck.
I have no idea now what to try next. Go backwards to CS5.5 and try again? how many hours can I afford to waste on this.
@Marius, glad to hear you got your certificate issues out of the way. I never have any certs/provision issues, but I do export my .p12 certs from the Keychain Access tool on my Macbook Air. I do work on Flash Pro CS6 on a Windows 7 64 bit machine though.
@Robert, I feel your pain. I went a week trying to figure this out when I first posted this thread. The first time, I was able to resolve it by renaming the .ipa file compiled on my Windows machine to a .zip file (not to be confused with 'zipping' the .ipa file), then, transferring that to my Mac, unzipping the .zip file there, and then zipping the .app file in the Payload folder, and submitting that through Application loader. The second time I encountered this issue (this past week), it was fixed by making sure my extensions directory only contained the .ane files I was using.
Hope this may help,
with kind regards,
Well, actually, so far, I've made my trials using builds from FlashPro CS5.5,
but perhaps in my case there's a different cause.
So far, I've been using a virtual mac on windows (VMWare workstation 8, with OSX mountain lion installed on it).
Tomorrow, I'll have a try from a real mac of a friend (though I can hardly imagine how that would make a significant difference).
The name of my IPhone Distribution certificate as it was generated by apple is:
"IPhone Distribution: Marius Versteegen"
The second part equals the name of my private key.
The name of the Distribution Certificate thus contains spaces, as well as a ":" character.
Could it be that the presence of these special characters in the name of the distribution key
could be the cause?
"Application failed codesign verification.
The signature was invalid, contains disallowed entitlements, or it was not signed with an iPhone Distribution Certificate."
Or has it been working for you in similar cases?
Right clicking in KeyChain on my distribution certificate, selecting validation..,there's
a dialog with radiobuttons. The one next to "generic (certificate chain validation only)" is enabled.
I was wondering - perhaps the one below ("Code signing") should be enabled instead?
If I generate a key/certSigningRequest on one Windows machine it's just as sensitive as Mac. CSRs and keys seem to have a 1 to 1 relationship with the machines they're generated on. You cannot make a key/csr on one Windows machine, take it to a different machine and generate certs with it. They fail.
My particular setup was generate certs on Mac, use them during production on Windows. There's no issue with Windows using a .p12 generated from Keychain/Mac. I did that for a long time. Soon I just got sick of even starting my Mac so I started using OpenSSL to generate the certs. That's when I found that the machine that generates the CSR must generate certs and only those certs can be used. So that's what I do. I generate certs once and copy the .p12 anywhere I go.
The pain in the neck is every time I add a new app I need to regen certs. That requires either being on the original machine I generated my CSR from or completely revoking the certs and generating them again (requiring all apps to be rebuilt, ugh).
Marius ~ I never changed anything in Keychain. I installed WWDC, generated a CSR, let the provisioning portal generate a .cer, downloaded and installed in keychain. I was able to export a .p12 that I used for quite a long time.
I've only done a few ad-hoc apps with Adobe Flash Pro CS5.5 and had no issue signing those for enterprise store development. That was about 2 years or so ago. Around then I downloaded FlashBuilder 4.6 and I've been using that and/or command line adt to compile since then and never had any issue.
One thing I did remember reading, just to confirm, is unzipping the IPA just to grab the .app file and rezipping that did solve some users issues. Although FB4.6 and Flash generate pretty similar IPAs (FB has plenty of "Flash stuff in it"), there has never been any issue on submission on my side as long as I generated my apps on a machine with WWDC and my cert installed while compiling.
Apple definitely went well out of their way to make the entire process very painful. Strange for a company extolling the simplicity they demand in their products.
Then I guess I should try to give it a shot with FlashBuilder 4.6.
Before that, as my knowledge on this certificate stuff is rather poor - forgive me for asking some
more stupid questions - there's so much that can be different, and for something that's as vague
as this matter, anything different may imply "wrong".
Revoke everything that is revokable-
apparently that's only the distribution and developer certificate, along with the attached provioning profiles.
Looks like the same WDRC can only be re-downloaded.
* So no other revokings. Am I right?
* No need to create a new AppID, I can just use one from an app that I configured on ITunes Connect already.
Download & generate csrs and certificates all just using the machine where the compilation takes place (Windows machine)
with help of open ssl. Build Using FlashBuilder 4.6.
Before that, cleanup current certificates.
A On windows machine:
Iphone Developer cert
Iphone Distribution cert
* and perhaps as well (?):
Apple Iphone Device CA
* Did I forget anything?
Before upload on mac, cleanup KeyChain on mac:
1. remove certificates from KeyChain:
WDRC, Developer and Distribution.
2. remove private and public key from KeyChain.
(or is that dangerous? don't know how I got them - or how to get them back, if required)
3. Perhaps the "Apple Code Signing Certification Authority" in system root?
* Did I forget anything?
* Before upload on mac, is it necessary to add anything to KeyChain?
* Is it required to add any certificates to windows certificate manager anyway?
The p12 developer and distribution files are all that FlashBuilder will need to properly
sign the code, isn't it?
Many thanks in advance,
Here's a step by step (verbose) of what I do from the top when I setup for a new client (which I did just 3 days ago). If there's anything here that's different, I recommend you remove everything you have from before and start from scratch, as there are times when some ridiculously unforeseen item left over can affect your setup:
(a) On a Mac, open Keychain Access tool. Go to 'Keychain Access' in the main menu, then 'Certificate Assistant' --> 'Request a Certificate from a Certificate Authority'. On the Certificate information form, enter the email address you used for your iOS Developer Program account, for Common Name, use the name you have associated to your iOS Developer account (i.e. mine was a personal account, so it's just 'Alex Yamane'), leave CA email address blank, and choose 'Saved to disk', and save the .certSigningRequest file generated somewhere handy.
(b) Log into http://developer.apple.com/ with your iOS Developer account. Click on 'Member Center' at the top. Log in. Click 'iOS Provisioning Portal'.
(c) First of all, make sure you remove everything before you start this process. You need to go backwards when you remove everything, so make sure first, you go to the 'Provisioning' section, and remove all Provisioning profiles first (both Development and Distribution). Devices, you can leave alone. Go to the 'Certificate' section and remove all Development and Distribution certificates.
(d) Go to App ID, and create yourself a new AppID for your app, just to make sure so you're using everything fresh from the start.
(e) Now go to 'Certificates', and use the .certSigningRequest file. Also create one for Development using the same .certSigningRequest file. Re-click the tabs for each and they should refresh with your new certs there. Download each one. After you do, I recommend you rename them so you know these are the newest ones you just generated (it usually has a default ios_development.cer and ios_distribution.cer file name. If you haven't yet, make sure you also download the WWDR intermediate certificate if you haven't already.
(f) Go to 'Provisioning' section, and now create a new profile for 'Development'. Then go to the 'Distribution' tab and create one for the app_store and adhoc distributions. Save all 3 provisioning profiles.
(g) On your Mac, open Keychain Access tool. First if you haven't already, go to 'File'->'Import item' and choose the WWDR intermediate cert. Then, do the same for your Distribution Certificate (not Development certificate), I've had tons of trouble in the past when I first was starting out, because Adobe's website keeps talking about the Development cert, but you only need the Distribution Certificate installed (and just use the adhoc provisioning profile to development/test and the appstore provisioning profile for iTunes submission).
(h) Once you've imported your Distribution certificate, there should be an item under the 'login' section of the Keychains column on the left that looks like "iPhone Distribution: Marius Versteegen". Click the arrow next to that and expand it. When you do, you should see a little key icon and your name again. Right mouse on that, and choose "Export 'Marius Versteegen'". Choose file format .p12, and save this file somewhere.
(i ) Now take all of those certs and provision files over to your Windows machine. Fire up Flash Pro. Open your project, and use the new .p12 file for your certificate, and use the new appstore Distribution certificate and compile. You should now have a .ipa file that's ready for iTunes submission.
(j) For me, from this point on, I've described earlier in the thread how I get my .ipa file over to my Macbook Air and upload to iTunes.
Hope this helps,
Step by step guide with graphics from the Apple
In the case above - I'd rather not go deleting everything I already have, that's how I got in this mess. I deleted the original provisioning certificate that had expired. Instead of editing it, and thus renewing it.
That's a tip by the way. If you have an expired certificate - go to the Dev site, and open the cert to edit it. Don't do anything, just click your cursor into any field, then save it.The certificate will be renewed for another year.
However - if you have deleted it like I did ... :-( then too bad.
I'm trying to pull apart my p12 file so I can create a new one through the process, but so far haven't found a way to renew the cert itself.
Woohoo! :-) Holy Matrimony..
The ***** has uploaded!
Thank you Alex, Sinious and Robert, you're my heroes.
As it appeared, I needed two additional parts to solve the puzzle.
The first one, I realized when parsing through the list of checkpoints that Alex sent in:
I'm embarassed I didn't see that myself - that for the distribution, there is a different kind of profile.
When I was on the profile section of the provisioning portal, it appears I didn't realize the other tab
or realize that the developer and distribution certificate needed separate profiles.
Still, after that one, the signature failed problem remained.
Then, build with FlashBuilder 4.6.
The problem remained. - in retrospect, probably, because when I did export to release,
I failed to visit/discover the tab that decides on the additional includes - which would contain a lot
of trash (.fla's that build the swc's, the swc's and other build results)
Keeping in mind the earlier advice of Alex, I then moved all that crap out of the
In my case, it worked transferring the ipa via dropbox, uploading it without applying the zip-tric,
and with a virtual (VMware) mac rather than a real one.
Thanks thanks thanks!
That's great to hear. Now if all my visitors will leave ... :-) I can get back to trying to solve this problem here. But I think I may just keep drinking wine for today!
I'd like to try a few things that require a lot of concentration. Reading all the relevant bits on this post for example
Then taking that bit of advice about removing all the litter in the build directory. That's caught me before I must admit.
Sorry I'm still stacking turkey cranberry mashed tato sweet tato green bean casserole ham and squash sandwiches. I slept about 23.4 hours for the last 2 days .
Also the extra adobe info in the IPA won't get your app rejected. I've had no issue with the extra cruft in there. You just need your basic ducks in a row (valid dist cert/mobileprofile connected to a valid app id, uncorrupt IPA, horseshoe up your... erm some luck).
Ok I have a sandwich to make...
WoooHoo.... I am one happy bunny. Upload successfull at LAST.
Here's what I did. (and didn't do)
Firstly - I had created certificates all out of sequence. Idiot. The process is listed on the Developer site in order for a reason.
So I thought.
Ok, I created the distribution certificate and the p12 file, using the openssl thing. Easy.
However - what I had done wrong - I had continued to try to use the old original .mobileprovision file.
What I should have done.
Create the CERTIFICATE for Distribution
Delete the old provisioning file, and then
Create a New Provisioning .mobileprovision file and down load it.
Once I did that, recompiled, moved the ipa to the VMMac, and up it went.
simple really :-)