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

# 23 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:

- Section 23.1, "Support for Dynamic Trust Management"

- Section 23.2, "Signing RIAs"

- Section 23.3, "Deploying RIAs"

## 23.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 `java.security.SecureClassLoader`.

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.

## 23.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

### 23.2.1 Signing Tool

The format of the following tool for signing RIAs is supported:

- `jarsigner`: Signing tool shipped as part of the Java SDK

### 23.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: *********
       -----BEGIN NEW CERTIFICATE REQUEST-----
       MIIBtjCCAR8CAQAwdjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwE
       AYDVQQHEwlDdXBlcnRpbm8xGTAXBgNVBAoTEFN1biBNaWNyb3N5c3RlbX
       MxFjAUBgNVBAsTDUphdmEgU29mdHdhcmUxEzARBgNVBAMTClN0YW5sZXk
       gSG8wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALTgU8PovA4y59eb
       oPjY65BwCSc/zPqtOZKJlaW4WP+UhmebE+T2Mho7P5zXjGf7elo3tV5uI
       3vzgGfnhgpf73EoMow8EJhly4w/YsXKqeJEqqvNogzAD+qUv7Ld6dLOv0
       CO5qvpmBAO6mfaI1XAgx/4xU/6009jVQe0TgIoocB5AgMBAAGgADANBgk
       qhkiG9w0BAQQFAAOBgQAWmLrkifKiUYtd4ykhBtPWSwW/IKkgyfIuNMML
       dF1DH8neSnXf3ZLI32f2yXvs7u3/xn6chnTXh4HYCJoGYOAbB3WNbAoQR
       i6u6TLLOvgv9pMNUo6v1qB0xly1faizjimVYBwLhOenkA3Bw7S8UIVfdv
       84cO9dFUGcr/Pfrl3GtQ==
       -----END NEW CERTIFICATE REQUEST-----

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.

Note: 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".

### 23.2.3 Bundling RIAs as JAR Files

To use Jarsigner to sign RIAs, the RIAs must be bundled as JAR files. The Jar tool (command `jar ...`), which comes with the Java SE SDK, can be used for that purpose, for example:

    C:\Program Files\Java\jdk1.8.0\bin\jar cvf C:\TestApplet.jar .
    added manifest
    adding: TestApplet.class (in = 94208) (out= 20103)(deflated 78%)
    adding: TestHelper.class (in = 16384) (out= 779)(deflated 95%)

This example creates a JAR file `C:\TestApplet.jar` that contains all of the files under the current directory and its sub-directories.

After the JAR file is created, verify its content using the `jar` tool again, for example:

    C:\Program Files\Java\jdk1.8.0\bin\jar tvf TestApplet.jar
     0 Mon Mar 06 18:02:54 PST 2000 META-INF/
     68 Mon Mar 06 18:02:54 PST 2000 META-INF/MANIFEST.MF
     94208 Wed Mar 10 11:48:52 PST 2000 TestApplet.class
     16384 Wed Mar 10 11:48:52 PST 2000 TestHelper.class

This ensures that the class files are stored with the proper path within the JAR file.

### 23.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/manifest.mf
        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
        X.509, EmailAddress=server-certs@thawte.com,
        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.

### 23.2.5 Microsoft Authenticode

Authenticode is a proprietary signing technology used in Microsoft Internet Explorer on Win32 for supporting signed applets in IE's JVM. Authenticode is not supported in Java Plug-in. Instead, the Java Plug-in supports use of signed applets in IE.

## 23.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 21.5, "Security Dialogs" for information.

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

### 23.3.1 Certificate Management

The Certificates dialog from the Java Control Panel manages signed RIAs. Access this dialog from the Security tab by clicking Manage Certificates. The Certificates dialog contains a list of certificates that received "Grant always" permission. Users can remove any certificate from the list, and if a RIA signed by a removed certificate is encountered again, a security dialog is shown to ask the user for permission. Users can also export and view certificates through the Java Control Panel.

Contents Previous Next

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