Skip to main content

Workaround for Java 8u131 “attempted to open sandboxed jar xxxxx as a Trusted-Library” error

A recent Java update to Java 8 build 131 changed what Java would accept as a “signed” JAR app. Specifically, any JAR signed with an MD5 hash will no longer be considered trusted, as the MD5 hash is now considered to be weak.

This change results in applications refusing to run with an error message like:
preloader: Delivering: ErrorEvent[url=https://XXXXX label=attempted to open sandboxed jar https://XXXXX/.jar as a Trusted-Library cause=attempted to open sandboxed jar https://XXXXX/.jar as a Trusted-Library

This occurs when the site delivering the applet is signing it with an MD5 hash. I’ve seen reports of the PulseSecure PCS and Cisco ASA doing this with the HOBsoft HOBlink Java RDP client, meaning that users are unable to securely access systems behind these devices.

PulseSecure have a workaround for their PCS –https://kb.pulsesecure.net/articles/Pulse_Secure_Article/KB40580.

Cisco do not currently have a solution.

The simplest workarounds are:
a) downgrade to an earlier release of Java, or
b) re-enable MD5 hash as an acceptable cipher.

Here’s how to do the latter on Windows and macOS (OS X). It involves editing the “java.security” config file which the Java Virtual Machine uses.

Windows (tested on Windows 10)

You will need local administrator access for this.
Close browsers and any Java apps

Open CMD as Administrator

cd "C:\Program Files (x86)\Java\jre1.8.0_131\lib\security"
notepad java.security

(The path may be C:\Program Files\Java\jre1.8.0_131\lib\security if you run the 64-bit Java)

Current Line:

jdk.jar.disabledAlgorithms=MD2, MD5,  RSA keySize < 1024

Change this to:

jdk.jar.disabledAlgorithms=MD2,  RSA keySize < 1024

(i.e. remove the “MD5,”)

Save the file

macOS Sierra (Mac OSX)

cd /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security
sudo vi java.security

Enter your password at the prompt so that you can edit the protected file.
Type “/jdk.jar.disabledAlg” to find the relevant line.

Current Line:

jdk.jar.disabledAlgorithms=MD2, MD5,  RSA keySize < 1024

Change this to:

jdk.jar.disabledAlgorithms=MD2,  RSA keySize < 1024

(i.e. remove the “MD5,” – use the cursor keys to move to the “MD5,” and press “x” to delete each character)
Save the file by holding down SHIFT and pressing “Z” twice.

Caveat: This workaround is disabling a security measure within Java, so should be considered a risk. However, the risk is only the same as the previous version of Java, and I would assume vendors will eventually update their systems so that they sign Java applets in a secure fashion.

This works with later versions of Java as well. I’ve tried it up to Java 8 Build 161. You do have to repeat the change after each upgrade though as it restores the MD5 text.

Adding a static route on VCSA 6.5

I recently upgraded my lab vCenter to the vCenter Server Appliance (VCSA) v6.5.

As I need a static route on my network, I went to add that in the same way that I’ve done for other VCSAs, only to find that the networking has changed.

VCSA 6.5 now uses systemd-networkd to control networking. Any attempt to use “service network restart” will generate a bunch of error messages about “exiting with error 6”. Editing files in /etc/sysconfig/network  will have no discernable effect.

So how do you add a static route under the new networking regime?

Log on to your VCSA using ssh (or the console) and start a shell.

cd /etc/systemd/network

There you will find all the network config files.

Typically you will have just one, named “10-eth0.network”.

The contents of this file are relatively self explanatory:

[Match]
Name=eth0
 
[Network]
Gateway=192.168.1.254
Address=192.168.1.40/24
DHCP=no
 
[DHCP]
UseDNS=false

Add a new section at the bottom of the file using your favourite text editor:

[Route]
Gateway=192.168.1.20
Destination=192.168.2.0/24

Again, the format for this is pretty obvious.
Once that’s saved, run:

systemctl restart systemd-networkd

Check that your route has taken using

root@vc01 [ ~ ]# ip route show
default via 192.168.1.254 dev eth0  proto static
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.40
192.168.2.0/24 via 192.168.1.20 dev eth0  proto static

Oracle Secure Global Desktop (SGD) fails on MacOS Sierra

I’ve recently been struggling to get the Oracle SGD desktop client working on macOS Sierra (10.12.3, specifically).

I’d installed Java, Firefox and XQuartz but kept getting a Java error saying “Failed to install SGD client”.

Here’s what I found I needed:

  • Java – because it’s a Java app
  • Mozilla Firefox – easiest way to run Java web apps on a Mac
  • XQuartz – the open source replacement for the Apple X11.app which used to be included with OS X.
  • The Oracle SGD Desktop client, usually available from the logon page for your SGD service.

If you have XQuartz 2.7.10 or later you will also need to run the following commands in Terminal:

sudo mv /opt/X11/lib/libXt.6.dylib{,.bak}
sudo cp /opt/X11/lib{/flat_namespace,}/libXt.6.dylib

My thanks to this Harris Geospatial web page for pointing me in the direction for that fix.

Some people may find it necessary to move the “Oracle Secure Global Desktop Client” from the main /Applications folder to your local user ~/Applications folder.