Documentation Contents
Java Platform, Standard Edition Deployment Guide
Contents    Previous    Next

25 Working with Signed RIAs

This topic provides information about working with the certificates used to sign Rich Internet applications (RIAs), which are Java and JavaFX applications that are embedded in a web page or launched from a browser.

This topic contains the following sections:

25.1 Support for Dynamic Trust Management

Java SE has a fine-grained access control based on "codesource" and "protection domain". Every class that is loaded from a JAR file has a codesource, which encapsulates the following information:

  • The location (URL) where the class came from. In addition, every class that is loaded by a classloader belongs to one and only one protection domain, based on its codesource, that is, based on where the class came from and who signed it. Every protection domain has a set of permissions associated with it, based on the configured security policy. The protection domain encapsulates the codesource and the set of permissions granted to it

  • The list of principals who signed it (its certificates). Each signer principal in the codesource is represented by its X.509 public-key certificate and supporting certificate chain.

A certificate chain is a list of hierarchically ordered public-key certificates, starting at the signer's public-key certificate and ending at the certificate of a Root Certification Authority ("Root CA"). The public key of one certificate in the chain is used to verify the signature on the previous certificate in the chain. The Root CA certificate is self-signed. The assumption is that the Root CA is trusted because it is well known and widely published.

Deployment class loaders check the configured security policy to determine which permissions to grant to a given codesource. The codesource and the set of permissions granted to it then form a protection domain. This behavior is common to all secure classloaders, that is, instances of

If the certificate chain can be verified all the way up to its Root CA certificate, the that Root CA certificate is checked to verifiy that it is contained in the database of trusted Root CA certificates. If so, the certificate chain of the authenticated signer is shown and the user is asked to grant AllPermission to code signed by that principal. Java code that is assigned the AllPermission permission is treated the same as system code, meaning it has all the privileges that system code has. The user can then choose whether to grant AllPermission to code signed by that principal, and whether such permission should be granted to any code signed by that principal for all subsequent sessions or for the current session only.

25.2 Signing RIAs

Signed RIAs are supported to make deployment of RIAs easier. This section provides step-by-step instructions for signing RIAs using certificates from a trusted Certificate Authority (CA), enabling novice developers to sign their RIAs without having to wade through the many complex security issues involved.

Signing applets requires the following items:

  1. Signing tool

  2. A keypair and a certificate chain for the public keys

  3. The RIA and all its class files, bundled as JAR files

25.2.2 Getting Certificates

Certificates can be purchased from a CA, such as VeriSign and Thawte. Some CAs, such as VeriSign, implement different protocols for issuing certificates, depending on the particular signing tool you are using.

Jarsigner is known to work with VeriSign and Thawte certificates and might work with Certificate Authorties. To use Jarsigner to sign RIAs, obtain code signing certificates for Java from VeriSign, Thawte, or similar certificates from other CAs. During the process of certificate enrollment, you will be asked to provide the certificate signing request (CSR). To generate the CSR, follow these steps:

  1. Use keytool to generate an RSA keypair (using the "-genkey -keyalg rsa" options). Make sure your distinguished name contains all the components mandated by VeriSign/Thawte, for example:

    C:\Program Files\Java\jdk1.8.0\bin\keytool -genkey -keyalg rsa -alias MyCert
    Enter keystore password: *********
    What is your first and last name?
    [Unknown]: XXXXXXX YYY
    What is the name of your organizational unit?
    [Unknown]: Example Software
    What is the name of your organization?
    [Unknown]: New Technology Company
    What is the name of your City or Locality?
    [Unknown]: Cupertino
    What is the name of your State or Province?
    [Unknown]: CA
    What is the two-letter country code for this unit?
    [Unknown]: US
    Is <CN=XXXXXXX YYY, OU=Example Software, O=New Technology Company,
     L=Cupertino, ST=CA, C=US> correct?
    [no]: yes
    Enter key password for <MyCert>
    (RETURN if same as keystore password): *********
  2. Use "keytool -certreq" to generate a certification signing request. Copy the result and paste it into the VeriSign/Thawte webform, for example,

    C:\Program Files\Java\jdk1.8.0\bin\keytool -certreq -alias MyCert
    Enter keystore password: *********
  3. The CA will send you a certificate reply chain by email. Copy the chain and store it in a file. Use "keytool -import" to import the chain into your keystore, for example:

    C:\Program Files\Java\jdk1.6.0\bin\keytool -import -alias MyCert -file VSSStanleyNew.cer
  4. Your certificate and its supporting chain have been validated and imported into your keystore. You are now ready to use jarsigner to sign your JAR file.


You must use either the same alias name for all of the above steps or no alias name, in which case the alias name defaults to "mykey".

25.2.4 Signing the JAR Files

When you have the certificates, the signing tool, and the JAR files for the RIAs, you are ready to sign the RIAs.

To sign applets using jarsigner, follow these steps:

  1. Use jarsigner to sign the JAR file, using the credentials in your keystore that were generated in the previous steps. Make sure the same alias name is specified, for example:

    C:\Program Files\Java\jdk1.8.0\bin\jarsigner C:\TestApplet.jar MyCert
    Enter Passphrase for keystore: ********
  2. Use "jarsigner -verify -verbose -certs" to verify the jar files.

    C:\Program Files\Java\jdk1.8.0\bin\jarsigner -verify -verbose
     -certs d:\TestApplet.jar
     245 Wed Mar 10 11:48:52 PST 2000 META-INF/
     187 Wed Mar 10 11:48:52 PST 2000 META-INF/MYCERT.SF
     968 Wed Mar 10 11:48:52 PST 2000 META-INF/MYCERT.RSA
    smk 943 Wed Mar 10 11:48:52 PST 2000 TestApplet.class
    smk 163 Wed Mar 10 11:48:52 PST 2000 TestHelper.class
     X.509, CN=XXXXXXX YYY, OU=Example Software,
     O=New Technology Company, L=Cupertino,
     ST=CA, C=US (mycert)
     X.509, CN=New Technology Company, OU=Java Plug-in QA,
     O=New Technology Company, L=Cupertino, ST=CA, C=US
     CN=Thawte Server CA, OU=Certification
     Services Division, O=Thawte Consulting cc,
     L=Cape Town, ST=Western Cape, C=ZA
     s = signature was verified
     m = entry is listed in manifest
     k = at least one certificate was found in keystore
     i = at least one certificate was found in identity scope
    jar verified.
  3. Your RIA has been signed properly. You are now ready to deploy your signed RIA.

25.3 Deploying RIAs

To deploy RIAs, follow these steps:

  1. Reference the JAR from the HTML page using archive, cache_archive, or cache_archive_ex format.

  2. Place the JAR file and HTML page on the web server.

When a RIA is started, the following items are verified:

  1. The RIA is correctly signed.

  2. The certificate chain and root CA are valid.

If the RIA is correctly signed and the certificate chain and root CA are valid, a security dialog is shown that prompts the user to accept or block the RIA. See Section 23.5, "Security Dialogs" for information.

If the user chooses to allow the RIA to run, it runs in the corresponding security context.

Contents    Previous    Next

Oracle and/or its affiliates Copyright © 1993, 2015, Oracle and/or its affiliates. All rights reserved.
Contact Us