# Java Deployment Rule Set via AD Enterprise CA

My goal is to get a Java Deployment Rule Set in place in my organization, but I do not want to pay third-party certificate authority for a code signing cert when we have a working CA running through Active Directory. I have followed what I think is the correct procedure to get this accomplished, however when I finally go to run any Java applet I receive the following error:

Can not verify self-signed Deployment Rule Set jar

The steps I followed are:

1. Exported our root CA certificate
2. Imported root certificate into cacerts in JRE install path
3. Imported root certificate into a personal keystore
4. Generated a CSR with keytool for a new cert with personal keystore
5. Submitted CSR to enterprise CA using certreq, with the "Code Signing" template
6. Imported that cert into the personal keystore
7. Created a very basic deployment rule set and compiled it into a jar
8. Signed the jar with the cert in the personal keystore from step 6
9. Copied the signed jar into \Windows\Sun\Java\Deployment\

The above steps all completed without error - nothing about invalid certificate chains or the like. I can see the root CA cert in the Java control panel and when I click on the Deployment Rule Set link in the control panel and view its cert, I see the cert from step 6 and it's parent CA, both of which have future expiration dates and correct information as far as I can tell. But I still receive the verification error when running any applet

So - is it simply not possible to do this, and we have to pay for a cert? Or am I (hopefully) doing something incorrectly? If anyone has any insight it would be greatly appreciated, thanks!

-
Just be careful with the paths if you are using a 64bit OS. I had to use C:\Program Files (x86)\Java\jre# as my path to get it to work. –  user265402 Jan 16 at 16:26

Fix found.

We had the exact same problem. I tried everything mentioned above and nothing work. Chrome does not seem to be pulling Windows Certificate manager properly or at least to verify the signature from our Enterprise CA. I tried adding our Root CA certificate and ever our Subordinate CA certificate to all system keystores unsuccessfully.

The issue is Chrome is only looking at the user keystores, not at the system keystores for some odd reason. After I added the RootCA certificate to the USER SIGNER CA, it worked.

Doesn't work: %JAVA_HOME%\lib\security\cacerts

Works: %USERPROFILE%\AppData\LocalLow\Sun\Java\Deployment\security\trusted.cacerts

Google or JAVA should fix this issue.

Now time to script the injection for our users.

-

Turns out that this only happens in both Chrome and Firefox, but not IE. I haven't tested with Opera or Safari. Chrome's certificate manager pulls up Windows' certificate manager, which already of course includes our enterprise CA's certificate, and adding that certificate into Firefox's certificate manager does not seem to have any effect. The Deployment Rule Set works perfectly in IE, though.

I only use Chrome because I am more comfortable with its dev tools than IE's - our users use IE and if you are using a Windows enterprise CA and connecting to old legacy systems with a mix of Java and ActiveX most likely your users are as well. I am going to mark this as the answer since switching to IE works for me, but I hope that in the future some solution can be found for the other browsers.

-

The issue is the certificate isn't in the Java cacerts file. The issue is explained in the My Oracle Support document "How to deal with certificates from non-trusted certificate authorities (Doc ID 1604086.1)," the java code-signing tutorial, or a blog post self-signed for a known community.

Essentially, you need to import your CA's certificate into your client machines' cacerts files. I ended up executing a command such as this after every JRE install before copying DeploymentRuleSet.jar:

 %JAVA_HOME%\bin\keytool.exe -importcert -keystore %JAVA_HOME%\lib\security\cacerts -storepass changeit -alias YOURCA -noprompt -file \path\to\root\certificate.cer 

You will need to issue that command for the right installation area:

• C:\Program Files\Java\jre# - For most users, this will be used by browsers that launch RIAs.
• C:\Program Files\Java\jdk1.#.0_#\jre - For development systems creating software and running through developer tools.
-
Thanks Rob, I appreciate the reply! I did import the root CA into the cacerts file initially but had no luck with Chrome or Firefox. It does work in IE, however, even without importing the root CA into cacerts. Were you able to get it working outside of IE this way? –  Julius Dec 31 '13 at 17:01
Julius- I was, indeed, able to get it working outside of IE with this method. Try verifying the JAR file from the command line and see what you see? Check for your certificates in the Java control panel applet, as well. –  Rob Dec 31 '13 at 20:44
I was able to see our root CA in the Java control panel before but there must be something else I'm missing. I will spend some time with this again when I get the chance, thanks! –  Julius Jan 2 '14 at 15:30

I struggled a lot with the same problem and I found a solution. The solution was to import my certificate in the certificates store in the Java console under the certificate type "Signer CA". Then I was able to run my self-signed applets also in Firefox and Chrome.

-

My problem was that the new Java update didn't remove the old DeploymentRuleSet.jar which was used only by some previous versions, and which in my case resides at:

C:\Windows\Sun\Java\Deployment\DeploymentRuleSet.jar


The file in this folder does not depend on where the Java installation folder is, and even after Oracle removed Sun name from Java (and, thus, changed some file locations in newer versions of Java), the file given above remained in the system, and it seemed that new versions of Java continued to use it.

After Oracle removed medium security setting for Java applets, everything related to Java stopped to work, just reporting that "Can not verify rule set jar", and no solutions given on internet helped.

I found this folder by scanning registry for Java string to clean everything related to Java from mu system and make a clean install, and it turned out that it was the problem. Why latest versions of Java continued to use this file?

Since I removed this jar file from the system (on my 3 computers it was the same problem on Windows 7, both 32bit and 64bit), Java works without problems, but I didn't find this solution anywhere on Internet.

-