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:
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.
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:
Signing tool
A keypair and a certificate chain for the public keys
The RIA and all its class files, bundled as JAR files
The format of the following tool for signing RIAs is supported:
jarsigner: Signing tool shipped as part of the Java SDK
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 (DigiCert), 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:
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): *********
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-----
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
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". |
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.
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:
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: ********
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.
Your RIA has been signed properly. You are now ready to deploy your signed RIA.
To deploy RIAs, follow these steps:
Reference the JAR from the HTML page using archive, cache_archive, or cache_archive_ex format.
Place the JAR file and HTML page on the web server.
When a RIA is started, the following items are verified:
The RIA is correctly signed.
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.
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.
