Working with Java Deployment Rulesets (Part 1)
From Java 1.7.0_40, Oracle have introduced a new feature called Java Deployment Rulesets. These rulesets allow you to define security and compatibility settings at the client level for a given URL. You can also optionally specify which version of the Java Runtime should be used on a per-URL basis.
To allow unsigned Java applets to run, you must change the Java security level to "Medium". The default is set to High. Note that, as of Java 8, the "Medium" security level is no longer available. With Java 8, the only two options you have available (regarding unsigned applets) is to either add the URL to the "Exception Site List" (http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html), or to add the URL to our ruleset which I will cover in this post.
In 1.7.x, once the security level is set to medium and you try to run an unsigned Java applet, you'll receive a warning like this:
To suppress this warning from appearing, there are a few steps you'll need to perform:
1. Generate a self-signed certificate pair (or use a certificate issued from a Trusted Certficate Authority).
2. Create your ruleset.xml
3. Encapsulate the ruleset.xml into a file called "DeploymentRuleSet.jar"
4. Sign the DeploymentRuleSet.jar file with your certficate.
5. Export your public certifcate and import it into the client's certificate store (C:\Program Files (x86)\Java\JREx\Lib\Security\CACerts).
6. Copy/Deploy the signed DeploymentRuleSet.jar file to C:\Windows\Sun\Java\Deployment
To generate a self-signed certificate, you'll need to generate a new key pair into a new keystore. You'll need to ensure you have the Java SDK installed, and in the "bin" folder run the following from a command prompt (as admin):
keytool -genkeypair -alias gurupackager -keystore MySecretKeystore.jks
You'll be asked a series of questions to generate a distinguished name, and after completion, the certificate pair will be generated.
Make the alias of the certificate something easy to remember and identify. In this case, I have simply named it the same as my blog.
<?xml version="1.0" encoding="UTF-8"?>
<ruleset version="1.0+">
<rule>
<id location="http://javatester.org" />
<action permission="run" version="1.7.0_67" />
</rule>
<rule>
<id location="http://www.atcviztool.nasa.gov" />
<action permission="run" version="1.6.0_45" />
</rule>
<rule>
<id/>
<action permission="default">
<!-- All standard message prompts are displayed -->
</action>
</rule>
</ruleset>
The first rule specifies that Java applets at http://javatester.org can also run without warning, and requires version 1.7.0_67 to run. Multiple versions (separated by "|", and wildcards (*) can also be used. E.g. "1.7.*" or "1.6.0_67|1.7.*"
The second rule specifies that Java applets at http://www.atcviztool.nasa.gov can run as long as Java 1.6.0_45 is installed. Note, that you can have multiple versions of the Java runtime installed concurrently (http://docs.oracle.com/javase/7/docs/webnotes/install/windows/patch-in-place-and-static-jre-installation.html). So, if the applet has known compatibility issues with other versions of Java, then using VERSION attribute in the action element is the solution.
The last rule is the catch all rule for everything else that isn't defined above. This should be your default security permission, and you generally you'd either want to warn the user with the default security prompt, or block it altogether. You can also customise the message that appears to the user if you wish. Refer to http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html for a list of valid settings.
Ensure that when you save the file, you use the UTF-8 text encoding.
To allow unsigned Java applets to run, you must change the Java security level to "Medium". The default is set to High. Note that, as of Java 8, the "Medium" security level is no longer available. With Java 8, the only two options you have available (regarding unsigned applets) is to either add the URL to the "Exception Site List" (http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html), or to add the URL to our ruleset which I will cover in this post.
In 1.7.x, once the security level is set to medium and you try to run an unsigned Java applet, you'll receive a warning like this:
To suppress this warning from appearing, there are a few steps you'll need to perform:
1. Generate a self-signed certificate pair (or use a certificate issued from a Trusted Certficate Authority).
2. Create your ruleset.xml
3. Encapsulate the ruleset.xml into a file called "DeploymentRuleSet.jar"
4. Sign the DeploymentRuleSet.jar file with your certficate.
5. Export your public certifcate and import it into the client's certificate store (C:\Program Files (x86)\Java\JREx\Lib\Security\CACerts).
6. Copy/Deploy the signed DeploymentRuleSet.jar file to C:\Windows\Sun\Java\Deployment
Generating Your Certificates
To generate a self-signed certificate, you'll need to generate a new key pair into a new keystore. You'll need to ensure you have the Java SDK installed, and in the "bin" folder run the following from a command prompt (as admin):
keytool -genkeypair -alias gurupackager -keystore MySecretKeystore.jks
You'll be asked a series of questions to generate a distinguished name, and after completion, the certificate pair will be generated.
Exporting Your Public Certificate
You need to then export your public certificate in preparation for this to be imported into the target computers certificate store. Run:keytool -exportcert -keystore MySecretKeystore.jks -alias gurupackager -file mycert.cer
Importing Your Certificate Onto Target Machines
The system certificate store is located at C:\Program Files (x86)\Java\jreX\lib\security\cacerts.
For most deployments this is typically what you should need to target. Therefore, you'll need to run:
keytool -importcert -keystore C:\Program Files (x86)\Java\jre8\lib\security\cacerts -alias gurupackager -file mycert.cer
Make the alias of the certificate something easy to remember and identify. In this case, I have simply named it the same as my blog.
Creating the RuleSet.xml
You'll need to create a ruleset.xml file that looks like this:<?xml version="1.0" encoding="UTF-8"?>
<ruleset version="1.0+">
<rule>
<id location="http://javatester.org" />
<action permission="run" version="1.7.0_67" />
</rule>
<rule>
<id location="http://www.atcviztool.nasa.gov" />
<action permission="run" version="1.6.0_45" />
</rule>
<rule>
<id/>
<action permission="default">
<!-- All standard message prompts are displayed -->
</action>
</rule>
</ruleset>
The first rule specifies that Java applets at http://javatester.org can also run without warning, and requires version 1.7.0_67 to run. Multiple versions (separated by "|", and wildcards (*) can also be used. E.g. "1.7.*" or "1.6.0_67|1.7.*"
The second rule specifies that Java applets at http://www.atcviztool.nasa.gov can run as long as Java 1.6.0_45 is installed. Note, that you can have multiple versions of the Java runtime installed concurrently (http://docs.oracle.com/javase/7/docs/webnotes/install/windows/patch-in-place-and-static-jre-installation.html). So, if the applet has known compatibility issues with other versions of Java, then using VERSION attribute in the action element is the solution.
The last rule is the catch all rule for everything else that isn't defined above. This should be your default security permission, and you generally you'd either want to warn the user with the default security prompt, or block it altogether. You can also customise the message that appears to the user if you wish. Refer to http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html for a list of valid settings.
Ensure that when you save the file, you use the UTF-8 text encoding.
-- End of Part 1 --
Part 2 to follow shortly
Comments
Post a Comment