Validate certificate and provisioning profile - iphone

On our iOS projects, we commit to the version control repository both the signing certificate and the provisioning profiles used to generate AdHoc and AppStore builds. This way, whenever a new developer downloads a new fresh copy of the app, he has everything he needs to create an AdHoc build for testers.
We are using Jenkins for Continous Integration, and I would like to have a script that does some sanity checks on the commited files. In particular, I'd like to check that the commited provisioning profiles were indeed generated with the signing certificate commited in the repository.
Does anyone know how to do this from the command line? I can't figure out the .mobileprovision file format, although it seems to be a signed binary plist file.


Answering my own question, I hope this helps someone else.
Turns out, the mobileprovision file is a PKCS7 digitally signed message. It is not signed with the developer's certificate, but with Apple's one.
However, the data that's signed is an XML plist that contains the public key of the certificate you use to sign your binaries.
So basically, the steps are as follows:
Extract the data from the PKCS7 file.
Extract the public-key from the p12 file.
Compare the two, and check if they are the same.
I managed to do this easily with Ruby, since it provides nice wrappers to OpenSSL. I left a script in Github, if anyone wants to use.
The relevant parts of the code are as follows:
profile = File.read(#profile_file)
certificate = File.read(#certificate_file)
p7 = OpenSSL::PKCS7.new(profile)
cert = OpenSSL::PKCS12.new(certificate, #certificate_password)
store = OpenSSL::X509::Store.new
p7.verify([], store)
plist = REXML::Document.new(p7.data)
plist.elements.each('/plist/dict/key') do |ele|
if ele.text == "DeveloperCertificates"
keys = ele.next_element
key = keys.get_elements('//array/data')[0].text
profile_cert = "-----BEGIN CERTIFICATE-----" + key.gsub(/\t/, "") + "-----END CERTIFICATE-----\n"
#provisioning_cert = OpenSSL::X509::Certificate.new(profile_cert)
end
end
# Compare #provisioning_cert.to_s and cert.certificate.to_s


Here is a blog entry I found that explains the structure of the .mobileprovision file: .mobileprovision files structure and reading
And thats how csr files are looking like: What is a CSR (Certificate Signing Request)?
I don't think that there is already a working solution out there exactly fitting your needs. That's probably not the answer you were looking for, but I hope that you will find a connection somehow.

Related

Create .key file knowing the key code of digital signature

I need to create a .pfx file starting from the digital signature contained in a smart card.
I have a smart card and I know the key code that allow me to create a .cer file, but not the .pfx. I tried using the "OpenSSL" utility but what I miss is the ".key" file.
How can I generate the .key file knowing the key code of the smart card?

You might be doing something here that you don't really want to do. Creating a certificate (the .cer file you mentioned) is a normal use case with smart cards where you use the smart card to sign that certificate. You don't get the "key file" because that's secured in your smart card.
In typical cryptographic smart cards you cannot export the key as this would invalidate the whole idea of having it physically protected.
PFX file as well as pkcs#12 container both include a certificate and the private key in the same container. And as you most likely cannot export your key from your smart card, what you are asking is not possible.

Why converting to PEM if P12 already works

I've just generated an APNS certificate (for push notification) that ends up to a P12 file.
I put this file on my server, associated to its password and the whole works: notifications are well sent to devices.
I read a lot of articles explaining how to convert a P12 file to a PEM file.
Question is: What is the benefit of a PEM file if the P12 already makes the job.

Some programs do not support reading the key and certificate from a PKCS #12 (*.p12) file. Others only support PKCS #12, and many support both.
Because your program supports PKCS #12 there is no need (or benefit) to convert to PEM.

Prevent application cache from extracting files on iOS

I have an iOS application, which stores all downloaded *.pdf files in its cache. Is there a way to prevent this data from extracting? Encryption or something else? Thanks in advance.

There are quite a few ways to encrypt files, and I'm sure everyone will have an opinion on the best way to do so.
In a project I've recently been working on, we've been using CommonCrypto (https://github.com/AlanQuatermain/aqtoolkit). Just take any NSData, encrypt it, and save it to a file, and vice versa. You can even write an easy Transformer by subclassing NSValueTransformer, which abstracts all of the encryption to one spot and you will never have to worry about it again.

You can protect PDF files with a password. I assume you create the PDF files not within the application but externally. For example you can use Preview.app in Mac OS X to secure existing PDF files with a password (Hit Cmd-P, then select PDF in the print menu and there you can set security options. Or even more simple: in the menu choose Export...).
In iOS you can then open the PDF files like this:
CGPDFDocumentRef documentRef = CGPDFDocumentCreateWithURL((__bridge CFURLRef)[NSURL fileURLWithPath:filePath]);
if (!CGPDFDocumentIsUnlocked(documentRef))
CGPDFDocumentUnlockWithPassword(documentRef, password);
...

There are actually 2 Documents folders in which your app can store content. One can be extracted, and one is private. Check the accepted answer in this ticket.
Access files in "private Documents" folder transferred with iTunes

Assuming you want the PDF files from getting extracted on jailbroken devices, the most straight forward approach would be along the following lines:
generate a random string during the first launch of the app
save the random string either in NSUserDefaults in state file inside your own app's sandbox
using this random string create a secret key using a deterministic but hard to figure out algorithm
use this secret key, which you don't store anywhere but always generate on demand, symmetrically encrypt your buffer with AES or something similar
You would probably find the source code here very helpful.

Keychain Access cannot save CSR to disk

I'm using Keychain Access to generate a CSR file and save it to disk. After pressing save, I cannot find the generated CSR file where I specified, although Keychain Access says "Your certificate request has been created on disk".
I've tried to specify different folder to save the file but failed.
Anyone knows the cause?

I was having this same exact issue. Initially I thought the issue was that I had an existing certificate selected, so I tried just selecting nothing, this also did not work. I finally was able to get it to work by selecting another public key before generating the CSR http://cl.ly/3M3g2S432F3L2n291C0B

Invalid iPhone Application Binary

I'm trying to upload an application to the iPhone App Store, but I get this error message from iTunes Connect:
The binary you uploaded was invalid. The signature was invalid, or it was not signed with an Apple submission certificate.
Note: The details of original question have been removed, as this page has turned into a repository for all information about possible causes of that particular error message.
For general information on submitting iPhone applications to the App Store, see Steps to upload an iPhone application to the AppStore.

It's been my experience that Xcode occasionally gets confused about which signing certificate to use. I got into the habit of quitting and restarting Xcode after any change to the code signing settings (and doing a clean build) to work around this problem.

I just wanted to mention that I too had the problem with zip from the command
line as well. The problem lies in the way it handles symlinks by default. Using:
zip -y -r myapp.zip myapp.app
Solved that problem.

I had the same issue and solved it this way:
The property certificates were installed on my development machine and mobileprovision.embedded was included in the distribution archive. After an hour or so of Googling and digging I found the source the error. Inside Xcode I had copied the Release configuration and created a new Distribution configuration and then changed the signing identity to my distribution certificate. However, even though it was updated in the GUI the project file was not updated correctly.
If you come across the same error, look in your [ProjectName].xcodeproj directory for the project.pbxproj file and open it in your favorite editor. Look for the Distribution section. My broken one looked like this:
C384C90C0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ARCHS = "$(ARCHS_STANDARD_32_BIT)";
CODE_SIGN_ENTITLEMENTS = "";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Distribution: Edward McCreary”;
GCC_C_LANGUAGE_STANDARD = c99;
GCC_WARN_ABOUT_RETURN_TYPE = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
PREBINDING = NO;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “F00D3778-32B2-4550-9FCE-1A4090344400″;
SDKROOT = iphoneos2.2.1;
};
name = Distribution;
};
C384C90D0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
CODE_SIGN_IDENTITY = “iPhone Developer: Edward McCreary”;
“CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Developer: Edward McCreary”;
COPY_PHASE_STRIP = YES;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = GenPass_Prefix.pch;
INFOPLIST_FILE = Info.plist;
PRODUCT_NAME = GenPass;
PROVISIONING_PROFILE = “DB12BCA7-FE72-42CA-9C2B-612F76619788″;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “DB12BCA7-FE72-42CA-9C2B-612F76619788″;
};
name = Distribution;
};
You can see the signing identity and provisioning profile are incorrect in the second section. Edit it to match the first section, rebuild, and you should be good to go. The final one looked like this:
C384C90C0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ARCHS = "$(ARCHS_STANDARD_32_BIT)";
CODE_SIGN_ENTITLEMENTS = "";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Distribution: Edward McCreary”;
GCC_C_LANGUAGE_STANDARD = c99;
GCC_WARN_ABOUT_RETURN_TYPE = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
PREBINDING = NO;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “F00D3778-32B2-4550-9FCE-1A4090344400″;
SDKROOT = iphoneos2.2.1;
};
name = Distribution;
};
C384C90D0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
CODE_SIGN_IDENTITY = “iPhone Distribution: Edward McCreary”;
“CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Distribution: Edward McCreary”;
COPY_PHASE_STRIP = YES;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = GenPass_Prefix.pch;
INFOPLIST_FILE = Info.plist;
PRODUCT_NAME = GenPass;
PROVISIONING_PROFILE = “F00D3778-32B2-4550-9FCE-1A4090344400″;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “F00D3778-32B2-4550-9FCE-1A4090344400″;
};
name = Distribution;
};
guids changed to protect the innocent

Same problem, different solution.
In my case, I was compressing the file using zip -r myapp.zip myapp.app
Turns out, the zip command screwed the bundle. Compressing it from the finder made it work.

I had the same issue and after trying several things - I removed the .plist entitlements from the Code Signing Entitlements (just left it blank) and it built fine and uploaded FINALLY.
Good luck all :-D

Another data point: for a while, my app went through. Now I've added support for in-app purchases, and suddenly it fails with an "Invalid binary/invalid signature" problem. Upon careful looking, I found out that the value of application-identifier in the entitlements plist file was off.
This, most likely, had to do with the fact that I've replaced the provisioning profile from a wildcarded one to a app-specific one (required for in-app purchases). The wrong app ID qualified under the old profile. It did not match the app ID in the info.plist, but apparently iTunes forgave that.
So, to recap:
info.plist: com.mydomain.foo
dist.plist: com.mydomain.bar
Profile: com.mydomain.*
is OK, while
info.plist: com.mydomain.foo
dist.plist: com.mydomain.bar
Profile: com.mydomain.foo
causes "Invalid binary".

See this link for the solution:
http://greghaygood.com/2010/09/04/invalid-binary-message-from-itunesconnect
The short answer is that "Eventually I double-checked my info.plist and discovered something. I added CFBundleIconFiles per the new guidelines, but there was an empty entry in the array list. I removed that and re-submitted, and it was finally accepted!"

I had the same problem aswell, when building I noticed the provisioning wasn't added in the build.
The fix for me was to set the build to the iphone device as where I normally use the simulator, but then it won't include the provisioning profile...
This might be a noob mistake. Normally you can't build to device, but when you do it for distribution you can.

Well, after repeating the steps several times, I was finally successful in uploading my app.
I don't know exactly what fixed it, but prior to the successful attempt, I closed Xcode and Firefox and restarted them. I guess one of those apps had some bad juju.

Here's an issue I ran into: I added the binary to Subversion before uploading. Comparessing/zipping the binary then included the hidden .svn directories, which messed up the code signing.

I tried various things after reading various posts including those above. What finally worked for me was starting completely over! I deleted every certificate and provisioning profile associated with my app.
I recreated a new development certificate and a new distribution certificate. I downloaded the intermediate certificate again. Then I recreated both the development profile and the distribution profile.
After installing the three certificates (I noticed the distribution had both private and public keys this time) and the two provisioning profiles (my distribution profile didn't get flagged as not having a valid certificate!), everything worked.
Once I made the decision to revoke everything and just start over, it only took about 5 minutes to create the new stuff and re-install.

I had a similar issue but in Monotouch. I found that my Release profile was set to use developer certs. It should look like this:

It seems this issue has many causes. Here's the solution to mine:
This applies to anyone who belongs to multiple development teams (e.g. your own apps, and your companies).
If you building the build with one set of credentials and re-signing it with a different one (e.g. for adhoc/appstore distribution), you must ensure that the build was originally built & signed with credentials belonging to the same iOS development team that the distribution credentials you are re-signing with belong to.
So don't build with "Indy Dev Inc" credentials then try to deploy with "Company Inc" credentials. Make sure you setup both "Company Inc" dev, and distribution credentials, and use them.
I posted more info about this on my blog: http://omegadelta.net/2011/06/09/fiendish-ios-code-signing-invalid-binary-issue/

I had the same problem. I was ready to throw in the towel on this problem but I figured it out when I went to check in my code using Murky. I always skim the diffs on the files that changed before I check in. When doing so this time I noticed that the project.pbxproj file had changed....and in the Distribution section the entry for “PROVISIONING_PROFILE[sdk=iphoneos*]” was blank.
Quiting and restarting Xcode didn't work for me. Instead, I went into both my project and target settings and changed the code signing to directly select my Distribution profile rather than relying on the auto-select feature. Doing this caused the project.pbxproj file to populate with the correct values even though the auto-select feature supposedly selected the exact same profile that I selected manually.
I need a beer...

After trying all of the other fixes listed here we logged a TSI with Apple. Having followed all the steps in Technical Note TN2250 our problem was caused because a sealed resource was missing or invalid. In our case it was ._.DS_Store.
The ".." is called an Apple Double file, and is the result of copying the Xcode Project folder, *unzipped*, onto and back from a file system that doesn't properly support HFS+'s 'resource forks' (used for code signatures). These extra ".." files result and cause code signing verification failure.
To clean the problematic Apple Double files from your Xcode project folder, run the dot_clean command on your Xcode project's folder, do a clean build, and then rearchive and reattempt your submission.
dot_clean /the/path/to/xcode/project
Note: You can just drag the project folder into the terminal to automatically populate the path
There is no message when you run the command but the project build might show a warning about the file when you next build. You can ignore this, the app will validate and submit successfully.

Resolved this by cleaning up the myProject.xcodeproj file (right click, open package), the package contained files from co-developer, after deleting these the problem was solved

For me the solution was creating a distributing certification at:
Apple Developer Provisioning Portal.

For what it is worth, I want to add what it was that fixed this issue for me. I had a ? (question-mark) in my app title that was causing the error.

I received an invalid binary, if the app does not use remote push notification, but I left the code for registering push and the callback delegates for registering/receiving remote notification uncommented, even if the code does not get used.
This is recent. My last submission last week was fine. This week, it returns invalid binary. Luckily, there is an email that explains the error.

I was having a similar problem, but I don't use entitlements.plist. However, after a dozen failed uploads, I checked my info.plist and discovered something. My CFBundleIconFiles array had an empty entry. I removed that and re-submitted, and it was finally accepted!
Seriously, how hard would it be for Apple to expose those kind of validation errors?
Edit: It's not immediately apparant where the CFBundleIconFiles are because they use a different name. In the project info view, Ctl click and select "Show Raw Keys/Values" and then you will see the references to CFBundleWhatever. In this editor's case, he was trying to use a non-existent icon=72-#2x.png file.

I tried all other proposed solutions, but nothing helped.
I ended up creating a new Xcode project and copy all my code and resources into it. That did the trick, and my app got placed into the review queue.
I can also recommend Apples technical notes on code signing for debugging/verification.

My two cents:
Download the latest version of the Application Loader. I've just updated and now get a different error message.

I just went through this hassle (again) but this time I found that my distribution profile had a status of "Invalid". If you think everything else is right, double-check the status in the portal and renew/re-download anything that isn't in the Active state.

I received an Invalid Binary after an app upload, with no e-mail followup as to why it failed. I tried doing a couple things at once, and I'm not sure which of the following actually fixed it:
Restarted Macbook Pro
Moved the source code for my project from an NTFS drive to an HFS+ drive and recompiled.

I had a problem with this and the 4.3 GM SDK. One of our apps would not make it past upload received. It turned out to be a provisioning profile issue. I regenerated the app store profile and it worked fine.

My solution involved creating a new App ID. I'm not sure exactly why that fixed it, but I suspect it may have been mismatched Bundle Identifiers — creating the new App ID forced me to make sure my app and iTunes were expecting the same thing.

Another solution:
For me simply setting the 'Release' certificates under 'code signing' fixed it. They were initially set to 'Don't code sign'.

For me the problem was solved by resaving a PNG image with the non-interlaced option. In previous versions interlaced png were allowed, but know this images can cause the invalid binary.
My apple message:
Corrupt Icon File - The icon file iconGQ#2x.png appears to be corrupt. Your icon must not be an interlaced PNG file.
You can see if the PNG is interlaced using the command "file" in the terminal:
Eva-Madrazos-MacBook-Pro-2:GQ 7 integracion ads Eva$ file *.png
Default.png: PNG image data, 320 x 480, 8-bit/color RGB, non-interlaced
Good luck,
Eva

I want to point out the possibility to email Apple and ask them to check their logs. I did just that, after having tried loads of things first. It was necessary to remind them after almost four weeks, but finally they replied and pointed to the exact spot of the issue.
The problem in my case was that I had previously tried other app icons, and a reference to the old image still remained in 'CFBundleIcons'. I used the drag and drop functionality to set the icon, but I didn't notice that the old content wasn't completely cleared before the new reference was added.
To see the faulty reference it was necessary to expand the arrows to view each and every sub element in the plist file. One tips is to right-click in the file and select the option for viewing the raw content. In that way you will not need to expand anything.

uuid is not allowed.
I fixed it by remove all [[UIDevice currentDevice] uniqueIdentifier];