Download Installing Older JREs

Working with Multiple
JREs
White Paper
Version: 1
Created: April 2, 2015
Author: Keith Rust
Overview
Have any of these scenarios happened to you?



I tried to open an attachment using AutoVue and I get a blank page.
I need to launch the Java Client, but the JRE required to run it is later than the version required
to run my <fill in the blank> application.
My security team says that I have to upgrade to the latest secure release of the JRE, but that
means it won’t be compatible with my other software.
Java Runtime Environment (JRE) releases are very common as they typically address security
concerns as well as introduce new features and functionality. Unfortunately, not all systems are certified
and operational with the latest JREs. To help address this issue Oracle released a feature with Java 7
update 40 called “Deployment Rule Set” that will allow installing the latest JRE while still allowing older
JREs to run with applications that require them.
In a nutshell, Deployment Rule Sets allow having multiple JREs installed on one machine and a file with
rules will specify which JRE to use for a given application. For instance, the rules may indicate that for
Agile use JRE 1.7, for EBS use JRE 1.6 and for everything else use 1.8. The solution is fairly simple,
but should be handled by a system administrator who can push out the configurations to multiple user
computers.
Here are a few good articles that explain how to use this feature:
https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html
Document1
Document Type
Page 2
Solution
Cutting to the chase, here is what we need to do:
1.
2.
3.
4.
Download and install the latest JRE (currently 1.8.)
Download and unzip (1.7) or install (1.6 and earlier) JREs.
Register each JRE with the Java Control Panel.
Create a file called ruleset.xml that contains one or more rules. Here’s an example:
<?xml version="1.0" encoding="utf-8"?>
<ruleset version="1.0+">
<rule>
<id location="http://myerpserver.inspirage.com"/>
<action permission="run" version="1.6*"/>
</rule>
<rule>
<id location="http://myagileserver.inspirage.com"/>
<action permission="run" version="1.7*"/>
</rule>
</ruleset>
a. What this rule is saying run any Java application (applet or Java Web Start) from
myerpserver using any version of JRE 1.6 and any Java application from myagileserver
using any version of JRE 1.7.
b. There can be multiple rule nodes, but in this case I just want to make sure I can run my
ERP system.
5. The ruleset.xml file needs to be packaged into a JAR called DeploymentRuleSet.jar and then
signed.
a. Examples on these steps are below.
6. Copy the JAR to the Java Deployment directory on the user’s computer
a. Windows: c:\windows\Sun\Java\Deployment
b. Mac: /Library/Application Support/Oracle/Java/Deployment
Note that Java applications may be configured to use a specific version of the JRE and that both the
rule and the Java app configurations must agree with each other, otherwise Java will not allow the
application to execute. Here’s an example of a JNLP file that requires version 1.6 or later. If our rule
said to use version 1.5 it won’t run as both the rule and the configuration must agree.
That’s it! Now the applications will open with their correct version of the JRE.
Document1
Document Type
Page 3
Details
INSTALLING OLDER JRES
I find the fastest way to find the old JREs is to use Google and search for “java archives.” At the time of
writing this paper the URL is http://www.oracle.com/technetwork/java/javase/archive-139210.html. From
this page there are links to various versions of Java.
Clicking on a Java SE version will display links to download the Java Development Kit (JDK – used to
build Java applications) as well as the JRE (used to run Java applications.) Select the JRE desired and
download the zipped JRE.
Document1
Document Type
Page 4
Unzip the gziped tarball (.tar.gz) file into any directory on the user’s computer. Open the Java Control
Panel (i.e., Control Panel >> Java on Windows machines.)
Click on the Java tab and then click the View… button to see the registered JREs.
Document1
Document Type
Page 5
Click the Find button and use the wizard to navigate to the location where the JRE was unzipped. The
new JRE will be added to the list.
PACKAGING THE JAR
Open a command prompt in the directory where the ruleset.xml file was created and run the following
command:
jar –cfv DeploymentRuleSet.jar ruleset.xml
This creates (c) the DeploymentRuleSet.jar file (f) in verbose (v) mode with ruleset.xml as the content.
Next, the JAR needs to be signed using an SSL certificate using the following command:
jarsigner –keystore <path to our keystore> DeploymentRuleSet.jar <our
certificate alias>
It’s best to use a certificate that is recognized by Java otherwise the Java cacerts keystore for each
JRE will need to be updated with the certificate.
Don’t have a certificate? Not sure how to update the cacerts file? No problem, keep reading below.
SELF-SIGNED CERTIFICATES
SSL certificates can be purchased from a known Certificate Authority (CA) and they are good for a
period of time, typically one or three years. The CA will issue the certificate and keystore, which can be
used in the JAR signing process above.
An alternative to purchasing a certificate is to create our own certificate using standard Java tools. Selfsigned certificates can be valid for 5, 10, 20, 100, etc., years, it’s completely our choice. Here’s an
example of creating a 2048-bit self-signed certificate that’s valid for 10 years.
keytool –genkey –keyalg RSA –alias ss_cert –keystore keystore.jks –storepass
mypassword –validity 3600 –keysize 2048
This command will create a new keystore file called keystore.jks (this can be named anything) that
contains the certificate with an alias of ss_cert (this can be named anything) and is encrypted with a
password of mypassword (this can be any password.) Now we’re ready to sign the JAR.
Document1
Document Type
Page 6
JAVA NOT RECOGNIZING SELF-SIGNED CERTIFICATES
So, we’ve got the JAR signed and deployed, but Java is still not allowing us to run our Java app! This is
due to Java not recognizing our self-signed JAR, which could have been signed by any hacker, and
Java is trying to protect us. To overcome this we need to add our certificate inside of the keystore to the
cacerts keystore that comes with Java (<JRE Home>/lib/security/cacerts.)
We need to get the certificate file out of the keystore used in the JAR signing process using the
following command:
keytool –export –keystore keystore.jks –alias ss_cert –file ss_cert.crt
This will create the certificate file called ss_cert (this can be named anything) from the keystore we just
created with the alias ss_cert. FYI, the alias is just a way to reference the certificate in the keystore as
there can be more than one certificate in a keystore, which is just a mini database of certificates.
Now that we have our certificate we need to add it to the cacerts keystore deployed with the JRE using
the following command:
keytool -importcert -keystore <path to JRE home>\lib\security\cacerts storepass changeit -alias ss_cert -noprompt -file <path to
certificate>\ss_cert.crt
Be sure to set the paths appropriately before executing the script. Note that each JRE will need to have
this executed as the cacerts file is unique to each JRE. FYI, the default password for the cacerts
keystore is changeit.
Document1
Document Type
Page 7