Java u51–Understanding Exceptions.Sites
In u45, Java released a ruleset file which was meant to solve system administrator’s problems with whitelisting sites and preventing popups on unsigned sites. The problem with the ruleset was it required administrators to leave their comfort zone and step into the Java developer world by creating jar files and signing them. When I heard the new version of Java came with a new way to whitelist sites, I was pretty excited. I thought Oracle finally included a system administrator friendly way to manage Java… I was wrong.
At first glance, this Exception.Sites file might seem like it has everything admins need. What more do you need to do other than whitelisting sites? Well there are a number of problems you’ll encounter using this method and I’m going to detail them here at the end of the post. If you wish to go ahead and use this method to manage Java (it’s not a horrible way to manage Java, it just isn’t the best way) I will show how you can centrally manage it with SCCM.
Oracle has said the exception.sites file is meant to be for users to manage while the deployment.ruleset is for users to manage. By default, exception.sites lives in the users profile at this path: C:\Users\UserName\AppData\LocalLow\Sun\Java\Deployment\Security
and each user manages their own site list through the Java control panel:
Administrators can change the location of this file for all users through two files in this folder: C:WindowsSunJavaDeployment
The first file you will want here is a file named deployment.config. If you have a fresh install of Java, you will probably have to create the folder and this file if they don’t exist. This properties file tells Java there are computer settings that need to be set. Any settings you set in the properties file will overwrite the user settings. The content of this file is:
deployment.system.config=C\:\\Windows\\Sun\\Java\\Deployment\\deployment.properties deployment.system.config.mandatory=false
The second file you need is deployment.properties. This file lists all the properties the admin has set for the computer. By default, there are no settings set so the file will probably not exist. Create it and put this line in:
deployment.user.security.exception.sites=C\:\\Windows\\Sun\\Java\\Deployment\\exception.sites
This line of code tells Java to use the exception.sites file in C:WindowsSunJavaDeploymentexception.sites instead of the user one. Make sure this file is in a location your users have read access to or this will not work. Also, if you set this and a user has write access to the file, they will be able to change the site list for all users who log into the computer. Java will not use the exception.sites list in their profile anymore.
And that’s it! Now you can manage the exception.sites list.
Why shouldn’t admins use this method? Well here is a little list:
- Oracle provides a better way to manage exceptions through the deploymentruleset
- This method only lets you whitelist. You can not set security levels, block sites, or set which version should be used on which site
- This method doesn’t accept wildcards.
- Users will not be able to add their own exceptions, so all needed exceptions will have to be set by you (this may be a positive, depending on the environment)
If you don’t care about these points, then by all means use the Exception.Sites file to manage Java. As I said at the start, it isn’t a horrible way to manage Java, it just doesn’t have all the features of the deploymentruleset.
Updated: March 07, 2014
How to add Java Exception Site List for all users
I need to use an old Java applet for a certain website, but newer Java versions cannot run it, as it has a self-signed certificate. Reading on Oracle’s Deployment Guide, I need to make my own deployment .JAR, with a proper certificate signing (not self signed), just to create the exception I need to run applets from a single domain. I have found that there is a %userprofile%\appdata\LocalLow\Sun\Java\Deployment\security\exception.sites file, obviously one for each user. In there, one per line, is a list of domains I can set to exclude from NOT being executed. When I add the domain name, the user gets a single prompt, then it just allows that domain for that user. Great. I know I could add this file to the Default user profile, for any new users being created. Unfortunately, I do not think that removing every user’s profile from each of the systems is the right way to go. I can push commands to computers, but the commands run as my user — I can’t use %USERPROFILE% for this. I do not want to put it in my login script, as I do not want the file getting large for users who constantly log in and off of systems. I also only want the single domain added to whatever is there, without wiping out the user’s preferences that may already exist. Because I do not want to wipe out their preferences, I thought of doing something along the lines of echo http://www.example.com >> %userprofile%\appdata\LocalLow\Sun\Java\Deployment\security\exception.sites , but that won’t work, as it will keep adding to the file. What can I do to add the list to the Exceptions rule, but only if the rule does not exist already?
( I am wondering why this was migrated from serverfault ). This is clearly meant for system administrators.
@Ramhound Wasn’t getting views, and can still be useful here. I requested the migration, and I will fix it up to be on topic here
How to manage Java’s control panel & Exception Site List
With the introduction of the Exception Site List in Java 7, many users have experienced havoc trying to manage all the exceptions needed for end-users in their environments. Through exhaustive research, I have found a way to manage Java’s control panel and Exception Site List from a system-level and have all the settings managed from a network share. I will show you how to collaborate your Java settings and Exception Site List into a couple of Packages to deploy throughout your environment using PDQ Deploy. These same steps work with Java 8.
First, let’s understand how the Java Control Panel settings are managed with a default installation of Java. The deployment.properties file is installed in a non-configurable location here:
The Java Control Panel and the Exception Site List can both be managed from the deployment.properties file, but the changes reflect only on a per user basis. However, the user level deployment.properties file can be bypassed if a deployment.config file is created that also points to a system-level deployment.properties file. By default, the system-level deployment.config, and deployment.properties files are not created. (Only the User level deployment.properties file.)
So, how do we set up the system-level settings for Java? First, we will need to create the three files needed to manage the Java Control Panel settings. The three files once created, will go in the %WINDIR%\SUN\JAVA\Deployment directory which if it doesn’t exist, will need to be created.
deployment.config file
The deployment.config file is used to specify the location of the deployment.properties file in your environment. Whether the deployment.properties file is located on the local machine or on a network share, the deployment.config file will only contain two properties:
deployment.system.config and deployment.system.config.mandatory
The deployment.system.config property is the file path to the system-level (enterprise-wide) deployment.properties file. (Utilize the file protocol for the file path)
The deployment.system.config.mandatory is a Boolean value. The default value for this property is false. If left as the default value, there will be an attempt to load the deployment.properties file specified in the deployment.system.config path. If the property is set to true, the attempt to access the deployment.properties file will still be made; however, if the file cannot be found or loaded, nothing will be allowed to run.
Here are two examples of the contents in the deployment.config file. The first points to the deployment.properties file on the local (target) machines.
This example points to a deployment.properties file on the HQ-Svr1 server in the deploy share.
deployment.system.config=file\://HQ Svr1/deploy/Sun/Java/Deployment/deployment.properties deployment.system.config.mandatory=true
deployment.properties file
The deployment.properties file is used to manage the settings in Java Control Panel. A complete list of available settings and values that can be used is found here:
In addition, the exception.sites file path is set here as well.
Here are two example deployment.config files. The first example shows the contents of a deployment.properties file which points to a local (on each target machine) exception.sites file.
#deployment.properties deployment.webjava.enabled=true deployment.security.level=MEDIUM deployment.security.level.locked deployment.user.security.exception.sites=c\:/Windows/Sun/Java/Deployment/exception.sites
The second example points to a network share on a computer named HQ-Svr1 with a Windows shared directory called Deploy.
#deployment.properties deployment.webjava.enabled=true deployment.security.level=MEDIUM deployment.security.level.locked deployment.user.security.exception.sites=//HQ-Svr1/deploy/sun/java/deployment/exception.sites
exception.sites file
The exception.sites file is a one URL per line list of sites that you want in the Exception Site List field found in the Java Control Panel. Nothing else goes in this file.
Now that we have the three files we need, it is time to put them to good use. Depending on the set up desired (files on the local machine or a network share), it will determine where you will place your files. For our first example, we will be deploying our files out to the local machine. In this case, copy the three files you created into your repository or any other location on your machine you desire.
Create a new PDQ Deploy package
Now that your three files are in your repository or another location on your machine, open PDQ Deploy and create a new package. Create a command step and delete the default install step. In the command field, we need to enter a command that will copy the three files needed into the %WINDIR%\Sun\Java\Deployment directory and also create the directory if it does not exist (only the deployment.config files needs to be copied over if you are storing the deployment.properties and the exception.sites files on a network share). We will use an xcopy command with a /I and a /Y to accomplish the copy task for us.(Type xcopy /? in a command prompt for a usage statement)
That is all there is to it. Push out the packages to the respective machines and be amazed as the Java Control Panel properties and exception list conform to your desires. If you open the Java Control Panel and click on the Security Tab, you should see the changes you specified in the deployment.properties and exception.sites files are set. Remember the user’s deployment.properties file will be bypassed by the system-level properties. If the system-level properties are removed, Java will revert to the users deployment.properties settings.
- If you store your Java configuration files on a network share make sure your users have Read access to the shared files.
- If your exception.sites file is set to READ ONLY then the exception.sites list in the Control Panel will not be able to be modified.
- The command step created to change the Java Control Panel settings and Exception Site List can be added to our Java 7 Update 51(and later) Packages in the Package Library, to install Java and have the settings applied all in one package. Trials to PDQ Deploy do not include full access to our package library. The trial does include access to some packages for testing purposes. To see the different levels available, see our Package Library page.