How-To Manage the new Java security prompts without using keytool

As explained by Oracle on their web (follow this link for the full details):


"Java 7 Update 21 introduced changes to the Java browser plug-in behavior that enable you to make more informed decisions before running the Java applet in the browser. "

In the case of  "Java application with a certificate from a trusted authority" if the user checks the option "Do not show this again ... " well ... they would not get prompted again. 

Yet some administrator could still want to manage some of those prompts for their environment. For instance to prevent such prompt for their intranet applications.

To do so, you would need to: 

1. Get the URLs of the web pages throwing those warnings. 

2. On a test machine, install a version of Java that is higher than 7u21 and ensure that there is no trusted.certs file under C:\Users\<UserID>\AppData\LocalLow\Sun\Java\Deployment\security (unless you want to update an existing keystore)

3. Then browse each of the URLs you would like to pre-authorize on behalf of the users and ensure that you check the box "Do not show this again ... " and click on Run.

This will create and add the signing certificate information to the C:\Users\<UserID>\AppData\LocalLow\Sun\Java\Deployment\security\trusted.certs file.

To deploy this file you have several options, you could be using a GPO to push this file to your clients, or include it into your java package, or if java is installed in your corporate image simply copy it to the image prior to capturing it.

The file should be copied to the SYSTEM Java security folder - this way it will apply to all users. - under: 

C:\Program Files (x86)\Java\jre7\lib\security

and eventually 

C:\Program Files\Java\jre7\lib\security ( If you use 64-bit browser and 64 bit Java add-on) .

Here is a screenshot of the settings of a GPO that was tested to push the file to the clients: 

Should you want to carry on updating the keysotre file to add new applications as time passes then simply copy you existing trusted.certs file to your test machine - as per step 2 above - prior to adding more exceptions.

I have noticed when testing that the method that consists of first adding the certificate as described above and then going to the Java control panel to export the certificate as a .cer file to finally use keytool to add the signing certificate details to a keystore file did not work for me.

I have compared a working and a non-working trusted.certs file and the only difference I noticed was the Alias.  When letting java do the job of updating the trusted.certs the alias created looked like:
deploymentusercert$tsflag$loc=https//secure.entrust.com:443java.util.random@973f09
or
deploymentusercert$tsflag$loc=https//java.com:443java.util.random@a549a8

and this was the only way it would work. 

I hope you enjoy this article, until next time ...