Posted on Leave a comment

Securing Java Runtime without crippling clients.

One of the issues I’ve run into with patching Java Runtime is that for the last few years,  unsigned / self-signed applets are blocked by default. You can whitelist websites on a per-system basis, but I ran into the need to deploy this to a number of systems. This seems way more complex than it has to be. Here’s how I build the Java Enterprise Deployment Ruleset.

The easy parts….
1. Get a code signing certificate from an authority trusted by your client systems. You need to be able to export it with private key.
2. Install JDK
3. Export cert as PFX, save into programfiles\jdk\bin
4. Rename .PFX to .p12
5. Create ruleset.xml per http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html

The difficult stuff.. now it will probably be easier for you than it was for me.
1. Create a JAR with the ruleset.xml:

[code language=”powershell”]jar -cvf DeploymentRuleSet.jar ruleset.xml[/code]

2. Import your .p12 certificate into a Java keystore.

[code language=”powershell”]keytool -importkeystore -srckeystore whatever.p12 -srcstoretype pkcs12 -destkeystore signing.jks -deststoretype JKS[/code]

You will be prompted to create a keystore password, also prompted for the password you specified when you exported your cert.

3. Find the private key for your cert in the keystore (hint: it’s before the date in the 1 entry listed)

[code language=”powershell”]keytool -list -keystore signing.jks[/code]

You will be prompted for the keystore password as well as the password you specified when you exported your cert.

4. Sign the JAR you created.

[code language=”powershell”]jarsigner -verbose -keystore signing.jks -signedjar DeploymentRuleSet.jar DeploymentRuleSet.jar long-key-name-here[/code]

You will be prompted for the keystore password as well as the password you specified when you exported your cert.

The wrap-up…
1. Verify the JAR is signed OK

[code language=”powershell”]jarsigner -verify DeploymentRuleSet.jar[/code]

2. Test the DeploymentRuleSet locally
Copy DeploymentRuleSet.jar to C:\Windows\sun\java\deployment.
Check the “Configure Java” app, the Security Tab should display “view the Active  Deployment Rule Set”.
The resulting window should include the file’s contents as well as “DeploymentRuleSet.jar is valid”

3. Deploy the JAR to clients
The signed JAR should be placed in C:\Windows\sun\java\deployment on clients. I use GPO to achieve this. You could also create a PowerShell script to copy the file and an application in ConfigMgr with a detection method based on file and modified date. This would allow you to update the source content’s JAR, then update content on the deployment type, then update detection method… which would force clients to reevaluate the app.

Sample of what’s in ruleset.xml:
[code language=”xml”]
<rule>
<id location="http://whatever/Whatever"/>
<action permission="run"/>
</rule>

<rule>
<id/>
<action permission="default">
<message>
This application requires additional configuration to run.
Please submit an email to Help Desk.
</message>
</action>
</rule>
[/code]

Leave a Reply

Your email address will not be published. Required fields are marked *