Skip to end of metadata
Go to start of metadata

As of Java 6 update 19 all beans, plugins and additional plugin/bean libraries in a Servoy installation need to be signed, due to tighter security restrictions in Java WebStart.

Without signing, Java WebStart will present the user with a warning dialog upon starting a Servoy Smart Client. Due to bugs in Java 6 update 19, this dialog cannot be dismissed, effectively stopping the user from using the Servoy Smart Client.

As of Servoy versions 5.1.2, 4.1.6 and 3.5.11, a default Servoy installation will only contain properly signed libraries and thus works out-of-the-box.

However, when additional beans and/or plugins (with or without additional libraries) are added to the Servoy installation, they need to be properly signed as well. Most 3rd party plugin and bean developers have released new versions of their plugins and/or beans with proper signing (or will do so shortly). However, if those are not (yet) available, the existing libraries need to be signed "manually". 

This tutorial explains the process of signing unsigned libraries in Servoy installations.

When to follow this tutorial

This tutorial should only be followed when running a Servoy Application Server that contains 3rd party plugins and/or beans that are not signed. This tutorial is not applicable for default installations.

Library signing

"Signing" a library (.jar file) means the file (which is contained in the .jar file) will contain MD5 hashes for the contained classes. This way, when the library is used in a Java program, the Java program can verify the signatures and thus the integrity of signed JAR files. 

The signing of a library is done using a certificate. There are two types of certificates:

  • Self signed certificates: When a self signed certificate is used, the user of the Servoy Smart Client will be presented with a Java WebStart dialog when the Smart Client is started whether or not it trusts the certificate. This dialog has an "always trust" checkbox.
  • Certificates signed by a trusted third party: When a certificate is used by a trusted 3rd party, the user will not be presented with the warning dialog.

See Creating a keystore with a self signed certificate for instructions how to create a self signed certificate
See Authorize a self signed certificate by a trusted 3rd party Certificate Authority for instructions how to create a certificate signed by a trusted 3rd party.

Once a certificate is available for signing, proceed to the next paragraph for more information on how to sign all unsigned beans and plugins.

Validation & Sign tool

Servoy has donated a tool to quickly validate the entire Servoy Application Server for the existence of unsigned libraries and optionally sign the unsigned libraries as well. For further support please go to ServoyForge

The Validation & Sign tool can be downloaded here.


Unzip the downloaded file into the ../application_server directory of the Servoy Application Server 

Installation validation
To validate the Servoy Application Server installation, execute the following command from the command line in the ../application_server directory

java -jar signtester.jar

If the tool finds unsigned libraries, it will report them.

Signing unsigned libraries

If the installation contains unsigned libraries for which no signed version is available, the Validation & Sign tool can be used to sign all the unsigned libraries. In order to sign the libraries a certificate is required, see #Library signing for more information on obtaining a certificate.

Make sure the Servoy Application Server has been shut down, then run the Validation & Sign tool again with the following arguments:

java -jar signtester.jar mykeystore.ks yourpassword MyPlugins
  • 1st argument: "mykeystore.ks": the location and name of the certificate/keystore file (see previous paragraph)
  • 2nd argument: "yourpassword": the password used when generating the keystore
  • 3rd argument: "MyPlugins": The alias used when generating the keystore

Shutdown the Servoy Application Server

Before running the Validation & Sign tool to sign libraries, shut down the Servoy Application Server. It the Servoy Application Server is running, the libraries will not be properly signed.

This will effectively sign all previously unsigned libraries with the provided certificate. After completing this step, proceed to the next paragraph.

Plugin JNLP

When the Servoy installation utilized third party plugins that have dependencies on additional libraries which are managed through a plugin specific .jnlp file, the jnlp files also needs to be modified. The following needs to be added to the JNLP:


Locating plugins with dependancies on additional libraries managed through a plugin specific .jnlp file

All plugins in a Servoy installation are located in the ../application_server/plugins folder. The folder contains all the plugins that ship with Servoy by default plus any additional plugins that might have been added. When done properly, all .jar files in the directory are plugins and required additional libraries are located in sub directories. Plugin specific .jnlp files have the same name as the plugin they belong to, but with the extension.jar.jnlp instead of just .jar

Restart the Servoy Application Server

When the libraries are signed and the plugin jnlp files are updated, the Servoy Application Server can be started again and Servoy Smart Client should be able to connect again.

When still experiencing problems, first clear the Java WebStart cache on the client machine and see if the problem persists. If it persists, please post your findings on the Servoy Forum in this topic.

  • No labels


  1. Anonymous

    When you make use of the latest versions of our IT2BE Plug-ins and Beans for Servoy you do not have to sign the jars yourself.

  2. Anonymous

    There are also step-by-step instructions using a Comodo certificate reseller at

  3. Anonymous

    Same issue here  as described in the forum post

    The signtester.jar runs clean and everything passes. All existing JNLP files contain the all-permissions tag.  Yet we get the "mixed code" error that doesn't go away unless we alter the Advanced settings to disable checking for mixed code.

    Unfortunately the java console doesn't tell us what JAR is unsigned.