Signing JAR Files Used in Java Web Start

Java Web Start enforces a security sandbox. By default it grants any application, including application clients, only minimal privileges. Because Java Web Start applications can be so easily downloaded, Java Web Start provides protection from potentially harmful programs that might be accessible over the network. If an application requires a higher privilege level than the sandbox permits, the code that needs privileges must be in a JAR file that was signed. When Java Web Start downloads such a signed JAR file, it displays information about the certificate that was used to sign the JAR, and it asks you whether you want to trust that signed code. If you agree, the code receives elevated permissions and runs. If you reject the signed code, Java Web Start does not start the downloaded application.

The GlassFish Server serves two types of signed JAR files in response to Java Web Start requests. One type is a JAR file installed as part of the GlassFish Server, which starts an application client during a Java Web Start launch: as-install/modules/gf-client.jar.

The other type is a generated application client JAR file. As part of deployment, the GlassFish Server generates a new application client JAR file that contains classes, resources, and descriptors needed to run the application client on end-user systems. When you deploy an application with the asadmin deploy command's ----retrieve option, use the asadmin get-client-stubs command, or select the Generate RMIStubs option from the EJB Modules deployment page in the Administration Console, this is the JAR file retrieved to your system. Because application clients need access beyond the minimal sandbox permissions to work in the Java Web Start environment, the generated application client JAR file must be signed before it can be downloaded to and executed on an end-user system.

A JAR file can be signed automatically or manually. The following sections describe the ways of signing JAR files.

• Automatically Signing JAR Files

• Using the jar-signing-alias Deployment Property

• Manually Signing the Generated Application Client JAR File

Automatically Signing JAR Files

The GlassFish Server automatically creates a signed version of the required JAR file if none exists. When a Java Web Start request for the gf-client.jar file arrives, the GlassFish Server looks for domain-dir/java-web-start/gf-client.jar. When a request for an application's generated application client JAR file arrives, the GlassFish Server looks in the directory domain-dir/java-web-start/app-name for a file with the same name as the generated JAR file created during deployment.

In either case, if the requested signed JAR file is absent or older than its unsigned counterpart, the GlassFish Server creates a signed version of the JAR file automatically and deposits it in the relevant directory. Whether the GlassFish Server just signed the JAR file or not, it serves the file from the domain-dir/java-web-start directory tree in response to the Java Web Start request.

To sign these JAR files, the GlassFish Server uses its self-signed certificate. When you create a new domain, either by installing the GlassFish Server or by using the asadmin create-domain command, the GlassFish Server creates a self-signed certificate and adds it to the domain's key store.

A self-signed certificate is generally untrustworthy because no certification authority vouches for its authenticity. The automatic signing feature uses the same certificate to create all required signed JAR files. To sign different JAR files with different certificates, do the signing manually.

Using the jar-signing-alias Deployment Property

The asadmin deploy command property jar-signing-alias specifies the alias for the security certificate with which the application client container JAR file is signed.

Java Web Start won't execute code requiring elevated permissions unless it resides in a JAR file signed with a certificate that the user's system trusts. For your convenience, GlassFish Server signs the JAR file automatically using the self-signed certificate from the domain, s1as. Java Web Start then asks the user whether to trust the code and displays the GlassFish Server certificate information.

To sign this JAR file with a different certificate, first add the certificate to the domain keystore. You can use a certificate from a trusted authority, which avoids the Java Web Start prompt, or from your own company, which users know they can trust. To add a certificate to the domain keystore, see Administering JSSE Certificates in Oracle GlassFish Server 3.0.1 Administration Guide.

Next, deploy your application using the jar-signing-alias property. For example:

asadmin deploy --property jar-signing-alias=MyAlias MyApp.ear

For more information about the asadmin deploy command, see the Oracle GlassFish Server 3.0.1 Reference Manual.

Manually Signing the Generated Application Client JAR File

You can sign the generated application client JAR file for an application any time after you have deployed the application. As you deploy the application, you can specify the asadmin deploy command's ----retrieve option or select the Generate RMIStubs option on the EJB Modules deployment page in the Administration Console. Doing either of these tasks returns a copy of the generated application client JAR file to a directory you specify. Or, after you have deployed an application, you can download the generated application client JAR file using the asadmin get-client-stubs command.

Once you have a copy of the generated application client JAR file, you can sign it using the jarsigner tool and your certificate. Then place the signed JAR file in the domain-dir/java-web-start/app-name directory. You do not need to restart the server to start using the new signed JAR file.