iPack -The iOS Application Packager
Posted
by user13277780
on Oracle Blogs
See other posts from Oracle Blogs
or by user13277780
Published on Wed, 13 Nov 2013 13:43:17 +0000
Indexed on
2013/11/13
16:07 UTC
Read the original article
Hit count: 400
/JavaFX on iOS and Android
iOS applications are distributed in .ipa archive files. These files are regular zip files which contain application resources and executable-s. To protect them from unauthorized modifications and to provide identification of their sources, the content of the archives is signed. The signature is included in the application executable of an.ipa archive and protects the executable file itself and the associated resource files. Apple provides native Mac OS tools for signing iOS executable-s (which are actually generic Mach-O code signing tools), but these tools are not generally available on other platforms. To provide a multi-platform development environment for JavaFX based iOS applications, we ported iOS signing and packaging to Java and created a dedicated ipack tool for it.
The iPack tool can be used as a last step of creating .ipa package on various operating systems. Prototype has been tested by creating a final distributable for JavaFX application that runs on iPad, all done on Windows 7.
Source Code
The source code of iPac tool is in OpenJFX project repository. You can find it in:
To build the iPack tool use:
After building, you can run the tool:
Signing keystore
The tool uses a java key store to read the signing certificate and the associated private key. To prepare such keystore users can use keytool from JDK.
One possible scenario is to import an existing private key and the certificate from a key store used on Mac OS:
To list the content of an existing key store and identify the source alias:
To create Java key store and import the private key with its certificate to the keys store:
Another scenario would be to generate a private / public key pair directly in a Java key store and create a certificate request from it. After sending the request to Apple one can then import the certificate response back to the Java key store and complete the signing certificate entry.
In both scenarios the resulting alias in the Java key store will contain only a single (leaf) certificate. This can be verified with the following command:
When looking at the Certificate chain length entry, the number next to it is 1.
When an executable file is signed on Mac OS, the resulting signature (in CMS format) includes the whole certificate chain up to the Apple Root CA. The ipack tool includes only the chain which is stored under the alias specified on the command line. So to have the whole chain in the signature we need to replace the single certificate entry under the alias with the corresponding full certificate chain.
To do that we need first to create the chain in a separate file. It is easy to create such chain when working with certificates in Base-64 encoded PEM format. A certificate chain can be created by concatenating PEM certificates, which should form the chain, into a single file.
For iOS signing we need the following certificates in our chain:
- Apple Root CA
- Apple Worldwide Developer Relations CA
- Our signing leaf certificate
To convert a certificate from the binary DER format (.der, .cer) to PEM format:
To export the signing certificate into PEM format:
After constructing a chain from AppleIncRootCertificate.pem, AppleWWDRCA.pem andSigningCert.pem, it can be imported back into the keystore with:
To summarize, the following example shows the full certificate chain replacement process:
Usage
When the ipack tool is started with no arguments it prints the following usage information:
© Oracle Blogs or respective owner
