"Application failed codesign verification" - Pulling my hair out - validation

I'm trying to submit an update to my app. I had messed up some files, so had to generate from scratch all of my the certificates, keys, and provisioning files. Would that be a problem for updating? I read someone saying that updates to the app HAVE to be done using the same provisioning file... that can't be true, can it? Otherwise, I'm in major trouble.
Anyhow, my archive builds keep failing validation. I have triple checked that I'm using the Store Distribution certificate for my release. I also ran codesign command and it came through fine. I have also checked the contents of MYAPP.app bundle and the "embedded.mobileprovision" is there. Why does it say "Failed to load"?
Below is the output I get in my log. Any ideas?
(using XCode 4.0.2)
warning: Application failed codesign verification. The signature was invalid, or it was not signed with an Apple submission certificate. (-19011)
Executable=/Users/anna/Library/Developer/Xcode/DerivedData/MYAPP-fjmzhplryhwnsrgcsoyuivpwrojd/Build/Products/Release-iphoneos/MYAPP.app/MYAPP
codesign_wrapper-0.7.10: using Apple CA for profile evaluation
AssertMacros: signer, file: codesign_wrapper.c, line: 610
AssertMacros: profile, file: codesign_wrapper.c, line: 914
codesign_wrapper-0.7.10: Failed to load provision profile from: /Users/anna/Library/Developer/Xcode/DerivedData/MYAPP-fjmzhplryhwnsrgcsoyuivpwrojd/Build/Products/Release-iphoneos/MYAPP.app/embedded.mobileprovision
- (null)

You should remove your distribution certificate from your system. Revoke that certificate from developer portal, create a new one. delete the old provision profile and create a new provision profile for app store and use that.

I ended up resolving my issue by moving over to a different machine that had a clean install of all the dev tools. My original install got corrupted because I foolishly installed beta version over it and then tried to revert back, at which point codesign didn't want to play along anymore. I know that wasn't the smartest thing.. but sometimes you do things for the first time and learn the hard way :)
Anyhow, the good news is that new keys and certificates don't really mess things up and life can go on but watch where you install beta versions!

In dev center you can read that it is critical to store your private key somewhere save. It also says that this private key cannot be reproduced if lost.
Therefore I think you are in trouble.

Related

Xcode 9 automatic signing failing

I had successfully uploaded an app for TestFlight but after archiving and uploading now it is giving me this error I can't explain. Just to make sure I unchecked all entitlements in the capabilities target tab but that doesn't seem to matter.
I looked over all the app id's, certificates and provisioning profiles but there's nothing that looks abnormal. I would look in the actual .plist file generated by Xcode but I don't see where it is or if it even exists. Where should I even check to verify what's going on? Xcode is a buggy mess so I don't even trust this isn't some random bug (I cleaned the target of course just to make sure).
Automatic signing is unable to resolve an issue with the "..."
target's entitlements. Switch to manual signing and resolve the issue
by downloading a matching provisioning profile from the developer
website. Alternatively, to continue using automatic signing, remove
these entitlements from your entitlements file and their associated
functionality from your code. Then rebuild your archive and try again.
Provisioning profile failed qualification Profile doesn't match the
entitlements file's value for the application-identifier entitlement.
I had a terrible time with some old projects where I had to use manual signing because I couldn't get automatic provisioning to work. Then I discovered the following solution, which has worked for me 100%:
Switch to automatic provisioning if you haven't already.
Edit the target build settings and search for Sign. You should see four Code Signing Identity entries and they should all say iOS Developer. (If one of them says iOS Distribution, that's the kiss of death.)
Still editing the target build settings, search for Provision. Scroll down to the bottom and see if there is an explicit extra provisioning profile setting giving a profile number. If so, delete it.
Edit the target capabilities. Turn Game Center and iCloud and In-App Purchase on. Now turn them off again. This will give you an empty entitlements file (you can confirm this in the project navigator).
You will now be able to build to a device, archive, and export to the App Store, using automatic signing throughout.
I have had a very similar issue with Xcode 9.4, the only difference being that the error referred to issues with both the application identifier and keychain access groups entitlements.
I switched from automatic Xcode signing to manual signing to try to fix the problem. After some mucking about that did not help (and that I don't think contributed to fixing the problem) I ended up re-enabling the Xcode automatic signing. This appears to have fixed the problem. I was able to clean, archive and upload without any issues.
Not a particularly satisfying answer, but it worked for me.

XCode9: code signing blocked mmap() while running on device

I encountered the following issue after upgrading to XCode9 (Well I could not completely isolate the cause because I re-generated the certificate right after upgrading for enabling Push Service) :
dyld: Library not loaded: #rpath/apowo.framework/apowo
Referenced from: /var/containers/Bundle/Application/2CD5CA32-1DAF-423B-B921-024DCBEE2AF0/picatown.app/picatown
Reason: no suitable image found. Did find:
/private/var/containers/Bundle/Application/2CD5CA32-1DAF-423B-B921-024DCBEE2AF0/XXXX.app/Frameworks/apowo.framework/apowo: code signing blocked mmap() of '/private/var/containers/Bundle/Application/2CD5CA32-1DAF-423B-B921-024DCBEE2AF0/XXXX.app/Frameworks/apowo.framework/apowo'
There are several similar posts over SO but I believe it might be caused by something new. In fact the original issue was not on XXX.framework but libswiftcore, and after I have done all the suggestions on SO the error came from my own libraries. And here is what I have tried:
clean
delete the derived data
restart XCode, Mac, and my phone
delete all the certificates and recreate again
delete the framework references (and the binaries as well) from the project and re-add
None of them works.
Some additional data is I am using jenkins and fastlane to manage the build. The XCode project is re-created every time when the job runs. The same job runs well on another machine which is on XCode 8 and nothing breaks (runs after re-creation of the certs so it is with the new certs).
I thought it was about the libraries and I rebuilt them on XCode 9. The newly built libs were also in the XCode 8 built app and worked well but not on XCode 9.
Any help will be appreciated.
I have tried the following step and it's working:
In XCode -> Build Phase -> Linked frameworks and libraries: choose your particular framework status from required to optional.
And it should work ;)
I was having a very similar issue which ended up being a coding signing / Certificating issue. This article goes over two possible solutions in depth. For me, it came down to changing my Developer Certificate's trust levels.
Open Keychain Access: My Certificates > "Right Click" Certificate > get info > Trust > When using this certificates > Use System Defaults
"When using this certificates" should go from Use Custom Settings > Use System Defaults
https://blog.supereasyapps.com/how-to-fix-iphone-and-ipad-app-codesign-crashes-using-an-apple-developer-profile/
Had the same problem, and no matter how many times I recreated the certificate, cleaned the project or toggled the "use system defaults" vs "always trust" setting in the certificate — nothing helped.
What did help is noticing that while I had an Apple Worldwide Developer Relations CA in the keychain, my developer certificate was still "signed by an unknown authority" (only shows up when I double click it, there is no red cross near it in the list like for the expired ones).
It turns out apple has 5 different WWDG CAs — https://www.apple.com/certificateauthority/ You may want to check which was used to sign your profile (Issuer Name -> Organizational Unit: Gx) and download the appropriate one (or all of them). In my case, for example, I only had G1 installed, while a new certificate auto-created by XCode was signed by G3 that was missing in my system. Installing G3 (download and double-click or drop into the keychain window) solved the problem and I was able to run the application on my phone again.

Code signing issue with Sparkle auto-update

I am using Sparkle for the first time, and having troubles getting things off the ground. When I check for updates, it correctly detects a newer version, downloads it, unarchives it, and then gives the following error:
Update Error!
An error occurred while extracting the archive. Please try again later.
The output log shows the following detail:
Sparkle: The appcast item for the update has no DSA signature.
The update will be rejected, because both DSA and Apple Code
Signing verification failed.
My archive is named "MyApp.pkg.zip", and contains only "MyApp.pkg". It has an apple ID digital signature. I verified this by downloading the zip manually, extracting it, running the PKG, and clicking the lock icon on the first install page.
The PKG has been created using Packages.
My appcast has the following:
<enclosure url="http://thedomain/MyApp.pkg.zip" sparkle:version="1.0.0.990" length="5752133" type="application/octet-stream" />
My .app also has the same Apple ID signature as the .pkg, though I don't think it matters at this point of the auto-update process.
So my question is: What am I doing wrong? How is Sparkle concluding that the digital signature is not sufficient, when the PKG is clearly digitally signed?
Do you have different certificates for signing the .app and the .pkg? When you go to create the certificate on Apple's Certificates site, you have to choose one or the other type.
You need to have two certificates, one for signing the .app and one for signing the .pkg.

Xcode 6 continuous integration can't find provisioning profile

With Xcode 5 i was able to manually copy the profiles to where they needed to be. This is not the case with Xcode 6. I have added the server to the team and still cannot build. I can build fine from Xcode on the same machine. I get the following message:
Code Sign error: No matching provisioning profiles found: No provisioning profiles containing one of the following signing identities was found:
It should work since Xcode works but Apple keeps hiding these settings more and more and I'm left without a way to troubleshoot this.
It turns out I manually needed to copy the profiles to a new directory in /Library/Developer/XcodeServer/ProvisioningProfiles. Now I'm getting an error because "codesign" can't access the new special keychain apple is using for server, I can't access it either. Xcode 6.1 has a fix but I need server 4.0... It seems I can hack it but not sure if that's worth it or I should wait.

Sharing an archived iOS build won't succeed on the clients side - no such file or directory

For one of my clients, I've developed a small iOS app. I'm a member of their dev team, so I've been using a development certificate to sign my local test builds.
Now the app is almost done and it should go into internal testing on the clients side. I created an archived build of the app which I then sent to my client. They imported it into the organizer and tried to "Share" it to be able to re-sign it using an ad hoc profile.
Creating the .ipa fails with an "no such file or directory" error though. The archive appears to be fine otherwise - the organizer shows all the usual information, the icon, and it will let them export it as another archive. Creating an .ipa without re-signing fails as well, which leads me to believe this is not an issue with ther certs and provisioning profile.
If I try the same thing on my side, writing an .ipa from the very same archive using my development cert, the operation succeeds.
It may be worth mentioning that the same procedure was working fine while we were still using XCode 3.x on earlier projects. This is the first time we've been trying this using XCode 4.
No additional (static) libraries have been used.
Any help greatly appreciated!!
Edit:
Someone at the apple dev forums suggested to me that I should check the system console for xcode error messages while attempting to export the .ipa - none were printed out. We discovered some other, older messages however, which read as follows:
18.04.11 13:54:35 /Developer/Applications/Xcode.app/Contents/MacOS/Xcode[123] /Users/User/Library/Developer/Xcode/Archives/2011-04-15/Foobar.xcarchive/dSYMs/Foobar.app.dSYM/Contents/Info.plist:
set flags (was: 00200000): Operation
not permitted
The timestamp is roughly at the time when my client first imported my archive, but we can't be sure since we didn't watch the console back then.
The message had been printed multiple time, once for every single ressource file contained in the bundle. Does this tell you guys something?
Problem solved.
Following another suggestion on the apple dev forum, we repaired permissions on both systems. Additionally, I built and archived the app again and used a different way to transmit the archive to my client. We did all of this in one try, so I can't quite tell which of these measures actually did the trick. If you stumble across this because you have the same problem, you might want to try all of this, too.
Thanks for listening!
Update:
It happened again - and this time, we tried to solve it step by step. Result: It's all about how the file is being transmitted. I just attached the archive package to a mail to my client, that's what broke it, although I don't know why. Zipping the archive before transmitting it solved the problem, however.
After downloading XCode 4.3 beta with the IOS 5 SDK, the Organizer function to share and archive stopped working with a cryptic error "No such file or directory found".
It turns out that this is related to having two different versions of codesign_allocate . To fix the problem, do the following in a terminal window.
sudo ln -s /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate /usr/bin
Another hint - try the manual way to create a shared ipa - since it gives you a lot more detail of what went wrong. See http://blog.dmahajan.net
Can you see if this is also linked to your problem?
EasyCoder's answer fixed this issue for me - I have the 5.0 beta SDK and had the same problem.
I ran the following and it was fixed:
ln -s /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate /usr/bin/codesign_allocate

Resources