Category Archives: JAVA

jnlp (Java Network Launching Protocol) does not run from IE, only prompts to save

If you’re running a secure network, you may encounter a situation where you try to launch a Java web app (from an SSL session) and instead IE will only give you the option to save the jnlp file.  Assuming that your JRE version is current, this is likely due to the following Group Policy being enabled:

Computer Configuration | Administrative Templates | Windows Components | Internet Explorer | Internet Control panel | Advanced Page | Do not save encrypted pages to disk

This causes IE to block saving the jnlp file to the cache, which also precludes it from launching.

Java Runtime installation failure (Error 1330)

For security reasons, our network is completely disconnected from the Internet.  And I mean completely… we are not allowed to connect, ever.  In this situation, you quickly realize almost every vendor assumes you have Internet access (really? people still assume) and management of your network becomes harder by an order of magnitude.

As an example, earlier this week, I was trying to create an install package for the latest JRE, version 6 update 21.  I ended up getting an error 1330, invalid digital signature in data1.cab during the installation process.  After some research, I came across the following forum posts:

http://forums.sun.com/thread.jspa?threadID=5403715 and
http://forums.sun.com/thread.jspa?threadID=5380073
EDIT: Sorry, I know these links are broken, but Oracle changed the forum structure when Sun got gobbled by them and I haven’t had the time, or patience, to find where they went.  Personally, I consider this an HFE failure (the fact that the links broke when the site was migrated).  Shame on you Oracle.

Based on our connectivity (or lack of it), I realized this was due to the fact that JRE has a CAB file that uses a VeriSign code signing certificate that is NOT part of the Microsoft Root CA list.  To make matters worse, the CAB wants to run a CRL check that goes back to VeriSign.  After fiddling around trying different security options to bypass the CRL check, I finally gave up and went another way.

It turns out, that this issue only affects the JRE installer that is available for general consumer download.  The JDK, on the other hand, has a copy of the JRE as part of the package that doesn’t have this issue.  The bad part, is that the JDK makes you install, well, JDK stuff in addition to the JRE (which is an option).  Of course, I took this on as a challenge to split out the JRE as a standalone installer.

Most installers work the same way.  You download a single file and the file extracts all of the actual installation files into a temporary directory.  Since we only want the JRE from the JDK package, we will begin the install process.  Do not continue with the installer, or exit it.  Doing either action will cause the temporary files to be deleted.

At this point, the files are extracted to a temp directory located at:

C:\Users\<username>\AppData\LocalLow\Sun\Java\jdk1.6.0_21

(EDIT: This post was originally done with version 6 update 21.  Use the appropriate directory if your version is different.  This process has been most recently tested on version 6 update 25).  If you look inside this directory, you will see a msi file for the JDK along with a number of CAB files.

The one we’re interested in is the sj160210.cab file.  (EDIT: This filename is specific to the 32-bit version.  The 64-bit version may differ.  What you’re looking for is the cab that begins with ‘SJ’).  Double-clicking on this will show you the files within the CAB:

The jre.msi is the standalone JRE installer! You can use this by simply double-clicking on it, or rolling it as an SCCM package or script with msiexec support.  The adjacent MST files are language transforms (and are not needed for English).  Now, you can install JRE without the pesky CRL check!