Java Deployment Rule Set

While the Java Deployment Rule Set has been out for a short while now, I just got around to looking into it.

I initially had some doubts that I could get it to work how I intended, but after a short few hours, I had effectively disabled all java applications, except from the ones I explicitly had in my XML whitelist.

Backing up a little bit, everyone out there is aware that many enterprises have issues with upgrading to the latest java version. There have been many proposed solutions, some which work better than others, but in my opinion, there really hasn’t been anything that mitigates the risk significantly enough for the additional cost of any given solution. For example, using two browsers, one for internal use, one for web browsing, was a proposal I’ve heard thrown around. While this may work in theory, by doing this, an enterprise would incur more costs to keep the second browser patched and maintained, and more costs to build security controls around this new browser as well (policies to disable the ability for users to use a proxy, or using the intranet browser to go on the internet, ect), not to mention any additional installed software introduces additional risk just by being there.

In any case, after initially reading various articles, such as this one, this whitelisting concept sounded interesting, so I thought I would give it a try.


First, to set up my VM, I installed the following applications:

  1. JDK 7u40 (required)
  2. JRE 6u30 (any old version of java should work)
  3. OpenSSL for Windows (you’ll need a certificate to sign the JAR file)

After that, I mostly followed Oracle’s initial blog about Deployment Rule Sets, so some of the following is repeated, but I tried to give more detail, as some part’s were unclear in their blog if you just quickly wanted to throw together a POC.

Generate and Install Certificate

First, as you’ll need to sign the final JAR file, with OpenSSL installed, I ran the following commands to generate a PKCS12 file, answering the various questions as necessary:

cd C:\OpenSSL-Win64\bin

set OPENSSL_CONF=C:\OpenSSL-Win64\bin\openssl.cfg

openssl.exe req -x509 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt

openssl.exe pkcs12 -export -inkey privateKey.key -in certificate.crt -name jaxin -out server.p12

After everything was generated, I copied the various generated files to my desktop just to make things easy.

Next, I imported this certificate into Java by opening the Java Control Panel, going to the Security tab, and clicking on Manage Certificates.
Java Deployment Rule Set Import Cert1

From there, select the Signer CA drop down, and import the certificate you just generated.
Java Deployment Rule Set Import Cert2

Create and Install the RuleSet

Just for a simple test, I used the following ruleset and saved it to a file called ruleset.xml on my Desktop:

<ruleset version="1.0+">
    <id location="" />
    <action permission="run" version="1.6.0_30" />
    <id />
    <action permission="block">
      <message>Blocked by corporate</message>

In the real-world, you would have a rule for every white-listed internal application at your enterprise, but I just wanted to test this new functionality out. The first rule should allow Java applets in the domain to run fine, under version Java6u30. The second rule is a catch-all, and should block all other Java applets you browse to.

Now, in the command window, I ran the following:

jar -cvf DeploymentRuleSet.jar ruleset.xml

keytool -import -file certificate.crt -alias jaxin -keystore jaxin.jks

jarsigner -verbose -keystore server.p12 -storepass NA -storetype pkcs12 DeploymentRuleSet.jar jaxin

I then created the directory C:\Windows\Sun\Java\Deployment and copied the signed DeploymentRuleSet.jar file there.

Testing the RuleSet

Finally, the results 🙂

I navigated to, and I was presented with the following (Note: I enabled the Java Console to always display, just to see what happens)
Java Deployment Rule Set Result1

First, the Java 7 update 40 console appeared (left console appeared first), and appears to have checked the ‘whitelist’, and ran the applet under Java 6 update 30 (right console appeared second), just as the ruleset specified. The version the applet detected was in fact Java 6u30, which is what we were going for, as our “legacy” java software would break under the newer java versions 🙂

And, if we go anywhere else, whether it be intranet or internet, we are presented with the following:
Java Deployment Rule Set Result2

So everything appears to work as intended.


While this was just a quick POC, it was enough to show this actually has some promise as a solution to mitigate the risk an enterprise incurs by using legacy java applications.

There are some cons to this approach:

  • If not protected, the end user may be able to delete the DeploymentRuleSet.jar and bypass these restrictions. This mostly would affect corporations that allow their users to run as a local administrator, and so there’s less control over what the user does on their PC
  • There would be some overhead of managing this DeploymentRuleSet.jar file, storing the certificates, ect.
  • This is a new feature in Java, so there may be some bugs/vulnerabilities introduced (perhaps the white-list can be bypassed? I don’t know, I haven’t looked into how this feature works quite yet)

Still, I am thinking the benefits gained outweigh all the potential cons. Instead of flat out blocking java for the default rule, you can set the version to SECURE-1.7, which in theory will force users to have the latest/secure version of Java 1.7 installed in order to run all other Java applets they come across. While all versions of Java appear to be vulnerable to something, much of the risk of being infected would be mitigated by running the latest version of Java while browsing the internet.

So in conclusion, this (currently) appears to be a great risk-mitigation solution for enterprises who can’t (or don’t want to) remove or patch Java. I just hope that this white-list isn’t as easy to bypass as the JVM sandbox has been 😀

Leave a comment ?


  1. Thanks for the article, I tried to follow but when I go to with the same rule (I had Java 6 Update 32), the applet wasn’t showing up (Click for more errors), but the applet console logging did happen as what you said. Any ideas?

  2. If you replace the 4th line in ruleset.xml with:

    AND you have Java 6 update 32 installed, it should work for you. I just tested it and it seemed to work fine.

    What was the specific error shown if you ‘click for more errors’? There could be a number of reasons it didn’t work, so more details would help 😛

    Though without any more info – if the ruleset was the problem, you’d get a pop-up saying something to that effect (see the final screenshot)… so if you remove the files at C:WindowsSunJavaDeployment, does now work, or is the applet still erroring out?

  3. Thank you for your guide I have been able to get this working successfully finally on 1 machine. My question it seems that I need to import my certificate into the SIGNER CA on each machine before the DeplymentRuleSet.jar will work.

    Is this correct? our Trusted CA is already being pushed out via Group Policy into the correct locations on our Windows computers.

    If I need to import the cert into Java is there a way to do this via the windows command line to all the machines?

  4. The only way I know how to do it is through keytool, and importing the certificate into the JRE7 cacerts file.

    keytool -import -alias myprivateroot -keystore “C:Program FilesJavajre7libsecuritycacerts” -file certificate.crt -storepass changeit

    If you upgrade to Java 8 (when released), you likely will have to reimport.

    You also might be able to get away with copy/pasting the cacerts file from PC to PC, but I’m not sure how/if that file is encrypted, so that might not work, but I suppose it wouldn’t hurt to try it out.

  5. Thanks yes that ended up working for me somewhat. I found out I had to import my root and intermediate certificates there instead.

    • keytool -import -v -file root.cer -alias rootca1 -keystore “C:Program Files (x86)Javajre7libsecuritycacerts” -storepass changeit -noprompt

  6. Can’t you just copy and overwrite the CACERTS file from a PC with the cert already imported?

    Instead of using the keytool command?

    I just did this and it seemed to work.

    • Yes, that’s an option too. When I wrote the above, I was only testing with one PC, so didn’t have anyplace to copy it from. If you already have the cacert deployed to multiple computers, all you should need to do is push out the signed ruleset

  7. Hi Jaxin,

    Thanks for the great blog. I have been trying unsuccessfully to get your example working (using 6u35), but am getting the same result as ‘Tester’ was (ie. “Error. Click for Details”. When I click, a blank popup window appears for just an instant, barely long enough for me to read the title bar of the window “Application Error”, then it disappears)

    I have gotten this to successfully work with 3 various versions of Java 7 (7u45, 7u35, 7u9), but Java 6u35 and 6u27 are both giving me the same issues. I know that it is detecting 6u35 because both consoles are popping up (7u51 and 6u35).

    This is on Win7 Professional x64 w/SP1 with ie10. Any suggestions would be appreciated.

    • Since you see both consoles appear (7u51 and 6u35), it would seem that the Deployment Ruleset is working as intended.

      If this is an internal application, I presume it normally works with Java 6? So if Java 7 is not installed, so you’re not using Java Deployment Rulesets, and the only JRE is 6u35, does the application work? It kind of sounds like the application itself might be having an issue with the version (normal backwards comparability issues that java is known for).

      If it normally works with 6u35, or if it’s the java tester page I used in my example, I’m not sure what the problem is. I just tested using my ruleset with Java 6u35 running, and it seemed to work fine for me.

  8. every variance of this i have tried has failed. Trying to create a self signed cert with the java 7 update 51 sdk.

    I always get file not found. no rule set found when i try to view the rule set.

    Driving me NUTs!

    I create the xlm file.
    I jar it up.

    I create the self signed cert in the keystore file.
    I then explort the cert from the keystore and install it to the test system as a trusted root cert.

    I sign it and all looks good. I just can’t get java to see it. I always get Rule Set not found

  9. Hi! Please help! What am I doing wrong? I get this error after:

    C:Program FilesJavajdk1.7.0_51bin>jarsigner -verbose -keystore UCM.p12 -stor
    epass NA -storetype pkcs12 DeploymentRuleSet.jar jaxin
    jarsigner error: java.lang.RuntimeException: keystore load: failed to decrypt sa
    fe contents entry: javax.crypto.BadPaddingException: Given final block not prope
    rly padded

    • Change NA to the password you created after runing this command “keytool -import -file certificate.crt -alias jaxin -keystore jaxin.jks”

    • John Burke
      I sign it and all looks good. I just can’t get java to see it. I always get Rule Set not found

      I found this was caused by using paths when creating the deploymentruleset.jar.
      To resolve this create the ruleset.xml and copy it to bin folder , where jar.exe exists, then run the command; jar cf deploymentruleset.jar ruleset.xml

  10. Some quick research shows it’s likely related to a password on your keystore – here are some posts on stackoverflow that may help:

  11. I had this working great with Java 1.6.0_32 and Java 1.7.0_67…..including called jnlp RIA’s. Installed Java 1.8_25, never changed my Deployment Ruleset and now my jnlp called RIA’s are being blocked…..driving me nuts.

    btw…I found using the keytool was required for non IE browsers….and simply importing my signed/trusetd cert into the local computer CA store works just for IE.

  12. I have implemented a deployment rule set for our JRE enterprise deployments and it is working great. We are currently deploying JRE version 1.8.0_25. I have stumbled upon an internet site that I cannot get to run with the deployment rule set.

    My ruleset works with other sites, but it’s as though it is ignored for this site. Ruleset section for the above site is as follows:

    Any suggestions on how I can get this site to work?


  13. Rulset was lost in previous post, here it is without brackets:
    id location=”″
    action permission=”run”
    id location=””
    action permission=”run”

  14. application blocked by security setting…
    remove deployment rule set file from java

    pls help …
    how to reslove this issue .

  15. its urgent ….
    this impacting my work

    • Your question isn’t clear. If you are using a company device, and not an “IT admin”, you should talk to the appropriate team at your organization to request your tool to be added to the whitelist 🙂

      Otherwise, if you are the admin, follow the steps in the blog backward… it should be pretty clear how to remove the ruleset… or tweak it to add an application to the whitelist…

  16. Java Deployment Rule Set | - pingback on March 23, 2015 at 5:15 pm
  17. Hello, I have question I was hoping you could help me with. I’m creating jar file named “Deployment.jar” I have specific sites where I want only use an earlier version of jre.

    For example, I have both jre1.8.0_51 and jre1.8.0_66 installed.

    I want to use jre1.8.0_51 but when it loads, it fails because it’s still trying to run java1.8.0_66.

    I’m not sure what I’m doing wrong in the rule set. I’m able to create certificate and sign my Deployment.jar file with the hash. I’m guessing I might have something wrong in my XML?

    Any guidance would be appreciated.

    • Never mind, I figure it out. Once I enabled the Java Console, I could see what was happening. My problem was the XML file I created for the deployment ruleset was not parsing correctly.

      I used NotePad ++ and added one website at a time and saved it as XML. What I was doing wrong was copying and pasting another XML file into a new one. I think it was carrying over garbage or addition white spaces which could have throw the formatting off.

      Beware, if you have a java page that loads more than one session, you will experience some slowness. It will work, but it loads very slow.

      I found on the Java support website where it does mention this.


  18. Hey i have use you tutorial to creat the DeploymentRuleSet.jar!
    I have instal jre 1.70_51 and 1.5.0_22, when i try to run 1.5.0_22 the console of 1.7.0_51 give me:
    Missing Permissions manifest attribute in main jar!!

    Help me pls

  19. Nicole Made Thіs – Purveyor of the Best Bath Goodiees onn
    tһe Planet. Think homemade hummus, feta, rice wrapprd іn grape leaves.
    Ӏt is lovely to observe so mɑny couples att tһeir tables holding hands.

Leave a Comment

NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Trackbacks and Pingbacks: