To get your MIDlet suite digitally signed, you need to turn to a certificate authority (CA). Device manufacturers and mobile carriers are examples of certificate authorities, but they usually sign only the applications they distribute themselves. So normally you turn to well-known 3rd Party CAs like JavaVerified (external link), Verisign (external link) and Thawte (external link) who, among other signing services, provide services for Java application code signing. For information on which 3rd Party CAs are by default supported in Nokia devices, see Supported Root Certificates.
Signing processes vary between certificate authorities. In case of JavaVerified you submit your application to their process and once the application passes the acceptance criteria you get it back digitally signed as “JavaVerified”. In order to use the service of JavaVerified you need to acquire a Publisher ID which is used to identify the party providing the application. In case of Verisign and Thawte the process is somewhat different. You need to acquire code signing certificate from them and once you get the signing certificate you can use that for signing your applications an agreed period of time.
You can use one of the following options:
When publishing your application through Nokia Store, Nokia provides signing service free of charge. For more information, see the Publisher Guide on the Nokia Store Guidelines page.
For getting your application JavaVerified, see Getting Your App Java Verified (external link) and Java Verified (Nokia Developer Wiki).
To acquire a VeriSign code signing certificate, see Verisign Code Signing Certificates (external link).
To acquire a Thawte code signing certificate, see Thawte Code Signing Certificates (external link).
When using VeriSign and Thawte
or other similarly operating CA, the first thing to do is to acquire
a code signing certificate. Here are instructions for doing that by
using the keytool.exe tool (included with the
JDK) command line utilities:
Generate a public/private key pair.
keytool -genkey -alias mykeystore -keyalg
RSA -keystore keystore.ks
Fill in the asked information.
As result a keystore keystore.ks is created with
the given password.
Note: Make sure that you remember the passwords for the keystore and key pair you create, because they are needed later.
Generate a certificate signing request (CSR).
keytool -certreq -alias mykeystore
-keystore keystore.ks -keypass <password> -file request.csr
The command generates a certificate signing request file (CSR) request.csr.
Send the CSR to the selected CA for approval.
When purchasing the certificate from the CA the CSR file is copied to the purchasing form.
The CA sends you the signing certificate after approval process.
After approval the CA sends the certificate by e-mail. It looks like the CSR file, similar to this:
-----BEGIN NEW CERTIFICATE REQUEST----- MIAGCSqGSIb3DQEHAqCAMIACAQExADALBgkqhkiG9w0BBwGggDCCBOswggPToAMC ............ ............ ............ -----END NEW CERTIFICATE REQUEST-----
Save the certificate data to a text file and name it
for example mycertificate.cer. Make sure that
there is no NEW LINE character after the END NEW CERTIFICATE REQUEST line.
Import the signing certificate to the keystore.
keytool -import -file
mycertificate.cer -alias mykeystore -keystore keystore.ks -keypass
<password>
The command imports the new certificate to the keystore. Notice that the keystore needs to contain already the key pair used to generate the CSR (or in case of certificate renewal, the old certificate), otherwise the new certificate cannot be imported.
Typically code signing certificates are valid for a set period of time, for example one year. During this time the certificate can be used to sign MIDlet suites and install them to Java ME enabled devices, which support the CA that has provided the signing certificate. The root certificate of the CA, for example JavaVerified root certificate (UTI root), has to be supported by the device where application is wanted to be installed to. After the signing certificate has expired it cannot be used for signing, since the installation of such an application would fail. Note that already installed applications do not stop working even if the respective signing certificate has expired. Once the signing certificate expires it needs to be renewed through the provider CA.
Before the application is signed, you need to make sure that application properly requests all the permission it needs for using the protected APIs and functions. If a MIDlet suite is not using any protected APIs (or if it is not to be signed), it does not need to request any permissions. Requesting permissions is recommended also for unsigned application. Summary of Protected Methods is a comprehensive list of protected methods. To be able to use these methods from a signed MIDlet suite requires that permissions are properly requested.
The required permissions
are listed in the MIDlet-Permissions JAD attribute. If the application can operate without some of the permissions
it wishes to have, the permissions have to be listed in the MIDlet-Permissions-Opt attribute. An example of an application
that requires file read access for functioning properly but that can
survive without file write access:
MIDlet-Permission:
javax.microedition.io.Connector.file.read
MIDlet-Permission-Opt: javax.microedition.io.Connector.file.write
The two most common IDEs, NetBeans and Nokia IDE for Java
ME (Eclipse), have a built-in JAD editors, which the developer can
use to select the appropriate permissions to be requested. For example
in NetBeans this can be done in the Project properties view, by selecting the Application Descriptor category and from there API permissions tab.
It is recommended to use an IDE for this, because this minimises the
possibility of typing mistakes.
Example: Signing with NetBeans (tested in version 6.8):
The certificate must be added to a keystore (see Acquiring a code signing certificate).
The keystore
must be added to NetBeans by using the Keystore Manager.
Tools -> Keystores -> Add keystores
Every time NetBeans is launched, the used keystore and the certificate must be unlocked by using the password specified when creating the keystore, and the key pair for the certificate.
When you want
to sign an existing project in NetBeans, go to Project properties and select its Signing category.
Check the Sign Distribution box, select the correct keystore and
alias in the Signing menu (and unlock them, if
prompted).
The application is signed at build time.
Example: Signing with Nokia IDE for Java ME (Eclipse) (tested in version 3.5.1):
Add an existing keystore to Nokia IDE for Java ME (Eclipse).
Window
-> Preferences -> Java ME -> Signing
In the Navigator view , double-click a project Application
Descriptor, which opens the MIDlet suite specific settings
to the editor.
Select the Signing view, check the Sign generated packages and then select the key alias to be used.
Give the keystore password, if prompted.
You can use Scan for finding the needed permissions for the MIDlet.
Right-click
the project you would like to sign -> Mobile Tools for Java
-> Create package (and accept the prompts for the keystore
and certificate passwords).
For information on how to sign with command line tools, see Signing procedure using command line utilities.
For more information on signing, see article Packaging and Signing in the Nokia Developer Wiki.