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:
<openjfx root>/rt/tools/ios/Maven/ipack
To build
the iPack tool use:
rt/tools/ios/Maven/ipack$ mvn package
After building, you can run
the tool:
java -jar <path
to ipack.jar> <arguments>
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:
keytool -list -keystore <src keystore>.p12 -storetype pkcs12 -storepass <src keystore password>
To create Java key store and import
the private key with its certificate
to the keys store:
keytool -importkeystore \
-destkeystore <dst keystore> -deststorepass <dst keystore password> \
-srckeystore <src keystore>.p12 -srcstorepass <src keystore password> -srcstoretype pkcs12 \
-srcalias <src alias> -destalias <dst alias> -destkeypass <dst key password>
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:
keytool -list -v -keystore <ipack keystore> -storepass <keystore password>
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:
keytool -importcert -noprompt -keystore temp.ks -storepass temppwd -alias tempcert -file <certificate>.cer
keytool -exportcert -keystore temp.ks -storepass temppwd -alias tempcert -rfc -file <certificate>.pem
To export
the signing certificate into PEM format:
keytool -exportcert -keystore <ipack keystore> -storepass <keystore password> -alias <signing alias> -rfc -file SigningCert.pem
After constructing a chain from AppleIncRootCertificate.pem, AppleWWDRCA.pem andSigningCert.pem, it can be imported
back into
the keystore with:
keytool -importcert -noprompt -keystore <ipack keystore> -storepass <keystore password> -alias <signing alias> -keypass <key password> -file SigningCertChain.pem
To summarize,
the following example shows
the full certificate chain replacement process:
keytool -importcert -noprompt -keystore temp.ks -storepass temppwd -alias tempcert1 -file AppleIncRootCertificate.cer
keytool -exportcert -keystore temp.ks -storepass temppwd -alias tempcert1 -rfc -file AppleIncRootCertificate.pem
keytool -importcert -noprompt -keystore temp.ks -storepass temppwd -alias tempcert2 -file AppleWWDRCA.cer
keytool -exportcert -keystore temp.ks -storepass temppwd -alias tempcert2 -rfc -file AppleWWDRCA.pem
keytool -exportcert -keystore ipack.ks -storepass keystorepwd -alias mycert -rfc -file SigningCert.pem
cat SigningCert.pem AppleWWDRCA.pem AppleIncRootCertificate.pem >SigningCertChain.pem
keytool -importcert -noprompt -keystore ipack.ks -storepass keystorepwd -alias mycert -keypass keypwd -file SigningCertChain.pem
keytool -list -v -keystore ipack.ks -storepass keystorepwd
Usage
When
the ipack tool is started with no arguments it prints
the following usage information:
-appname MyApplication -appid com.myorg.MyApplication Usage:
ipack <archive> <signing opts> <application opts> [ <application opts> ... ]
Signing options:
-keystore <keystore> keystore
to use for signing
-storepass <password> keystore password
-alias <alias> alias for
the signing certificate chain and
the associated private key
-keypass <password> password for
the private key
Application options:
-basedir <directory> base directory from which
to derive relative paths
-appdir <directory> directory with
the application executable and resources
-appname <file> name of
the application executable
-appid <id> application identifier
Example:
ipack MyApplication.ipa -keystore ipack.ks -storepass keystorepwd
-alias mycert -keypass keypwd
-basedir mysources/MyApplication/dist
-appdir Payload/MyApplication.app
-appname MyApplication -appid com.myorg.MyApplication
