Troubleshooting the signing procedure

This section discusses common problems found when signing a MIDlet suite. Most of these problems are created during the signature procedure but may be spotted only at deployment time.

Certificate cannot be authenticated

A commonly encountered problem when installing a signed MIDlet is that its certificate cannot be authenticated. This would happen, for instance, if you would actually sign the suite with a self-signed certificate. It may also happen if the device does not include the certificate of your CA, or you have missed to put all the intermediate certificates in the JAD file, or if the root certificate of your CA is present on the device but disabled for Java authentication.

In that case, there will be an error message as shown in the figure below.

Figure 96: Unknown certificate

Note: With signed applets, the behavior when encountering an unknown certificate depends on the browser and local settings. In the end, the users can accept to trust an applet signed with an unknown certificate if he or she wishes to. In MIDP, this is not allowed. If the device cannot recognize the MIDlet suite, it will not be installed at all. This highlights the need for a certificate issued by a Certificate Authority rather than a self-signed one.

Corrupted MIDlet JAR file

A further problem, which the security framework is especially designed to detect, is the tampering or corruption of a MIDlet JAR file. If for any reason the JAR file has been modified, for example during the OTA transmission or while stored in a device, the integrity check depicted in section Trusted MIDlets will fail. This protects the user and the developer of maliciously or accidentally modified MIDlets. This is emulated by manually modifying the manifest file, and therefore making the SHA1 digest incorrect. The figure below shows this error in both the emulator and an actual device.

Figure 97: Tampered JAR file

Conflicting permission requests and domain permissions

Another potential problem is a mismatch between the permissions requested by the MIDlet suite and the protection domain's permissions. This can be tested in the emulator, for example, by misspelling the requested permission to javax.microedtion.io.Connector.htt. In this case, even though the application certificate is recognized and the MIDlet suite's integrity accepted, the requested permissions cannot be fulfilled, and the installation is aborted, as shown in the figure below.

Figure 98: Not enough permission (Eclipse view)

In the case of optional permissions, the MIDlet can be installed even if the domain does not contain those permissions (or they are misspelled).