Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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