Java deployment has change with version 8, and for us, it changed how we deployed it to all our workstations. We operate 100+ Windows Clients and Servers on a classified closed network. By closed network, I mean it is not connected to the Internet and has point-to-point WAN connectivity to remote sites which first must pass through a TACLANE type-1 encryption device. This creates some problems when it comes to 3-party Java code and signing.
Java version 8 is locked down quite a bit more as compared to previous versions. They have done away with the medium security level. There is only HIGH and VERY HIGH. Also, it will not allow code to run in a web browser if it’s not signed or trusted. This was causing problems when accessing our SAN switch interfaces and video-to-IP hardware interfaces via a web browser. We could not pull up the GUI’s to make configuration changes to the equipment, because Java would not permit the applets/code to run.
In addition, because we operate on classified DoD government network, we have to follow certain rules and guidelines mandated by the US Air Force Space Command, called STIGs. One such set of STIGs has to due with Java and how to lock it down at a system level. This blog entry provides some insight on what we did to lock Java down on our Windows 7 clients and servers, while at the same time allowing unsigned java code to run in the browser.
What’s written below is what we did in our environment. A different configuration may be better suited for your environment.
There are three text files that need to be created:
- deployment.config
- deployment.properties
- exception.sites
Java Deployment (deployment.config)
The contents of the deployment.config file consist of two lines shown below. The first line indicates that Java must find and use the deployment.properties file. The second line points Java to where that file exists.
deployment.system.config.mandatory=TRUE
deployment.system.config=file:///C:/Program Files/Java/deployment.properties
This file must be copied onto the local client workstation in the Java directory C:\Program Files\Java\version\lib\. Take special note of the syntax used to specify the path where the deployment.properties file can be found. It follows the same syntax you would use if opening the file on your computer in a web browser.
Java Properties (deployment.properties)
The contents of our deployment.properties file is shown below. This is where one can set the security level for Java (and a lot of other things) and lock it down so the users cannot change it. It’s also where we indicate that we want to use an exceptions.sites file that lists intranet web sites that are “trusted” to run Java in a browser.
deployment.security.enabled=HIGH
deployment.security.level.locked
deployment.user.security.exception.sites=C\:/Program Files (x86)/Java/exceptions.sites
This file can be copied anywhere (even to a remote file share via a UNC path). We just happened to copy it into the C:\Program Files\Java\ directory and made it a part of our latest client image. Take special note of the syntax used when specifying a path. You do not use double-quotes if there is a space in the directory path. Also, you must escape the “:” with a “\”. Lastly, you need to use “/” instead of “\”.
Java Exception (exceptions.sites)
The contents of the exceptions.sites file lists the URL paths to our SAN switches and other hardware that has Java GUIs that must be trusted to run on our network in a web browser.
http://10.0.0.1/
http://san-switch-1.domain.com/
http://san-switch-1/
This file can also be copied anywhere, but again we copied it to the same directory as the deployment.properties file above. Notice how I list the IP address, the FQDN, and just the DNS name in the file. However you enter the URL in the web browser is how it must be entered in the exceptions.sites file.
Once complete, Java deployment is much simpler and makes locking it down considerably easier than previous versions.
The post Java Deployment Configuration and Properties appeared first on WeatherImagery.
