Bug 480075 - javaws dies on invalid SSL certificates
Summary: javaws dies on invalid SSL certificates
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: java-1.6.0-openjdk
Version: 10
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Omair Majid
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 502225 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-01-14 22:22 UTC by James Ralston
Modified: 2012-01-17 20:22 UTC (History)
8 users (show)

Fixed In Version: 1.6.0.0-18.b16.fc10
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-05-29 14:07:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description James Ralston 2009-01-14 22:22:30 UTC
When a JAR file specified in a .jnlp file resides on a web server, javaws will attempt to download it.

However, if the URL for the JAR file is HTTPS, and javaws cannot verify the SSL certificate of the server, javaws silently fails to download the JAR file. javawa then dies due to an "error in opening zip file":

$ javaws jnlpgenerator-16 
netx: Launch Error: Could not launch JNLP file. (java.util.zip.ZipException error in opening zip file)
net.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Could not launch JNLP file.
        at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:372)
        at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:600)
Caused by: java.util.zip.ZipException: error in opening zip file
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.<init>(ZipFile.java:131)
        at java.util.jar.JarFile.<init>(JarFile.java:150)
        at java.util.jar.JarFile.<init>(JarFile.java:114)
        at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:345)
        ... 1 more
Caused by: 
java.util.zip.ZipException: error in opening zip file
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.<init>(ZipFile.java:131)
        at java.util.jar.JarFile.<init>(JarFile.java:150)
        at java.util.jar.JarFile.<init>(JarFile.java:114)
        at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:345)
        at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:600)

But this is deceptive, because the "error" in opening the ZIP file is that the ZIP (JAR) file was never actually downloaded!

If I manually download the JAR file in question, and place it in the netx cache directory, javaws dies with a different error:

$ javaws jnlpgenerator-16 
netx: Launch Error: Could not launch JNLP file. (java.lang.NullPointerException null)
net.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Could not launch JNLP file.
        at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:372)
        at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:600)
Caused by: java.lang.NullPointerException
        at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:358)
        ... 1 more
Caused by: 
java.lang.NullPointerException
        at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:358)
        at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:600)

But, again, this is a result of javaws balking at the SSL certificate that the server presents.

If I hand-edit the .jnlp file and change all instances of "https:" to "http:", and ensure the server supports both HTTP and HTTPS, then javaws launches and runs perfectly.

If I launch the .jnlp file using Sun Java's javaws, it warns me (via a pop-up window) that it can't validate the certificate, and asks me whether I want to accept it.

I think OpenJDK's javaws should do the same thing.

Comment 1 Lillian Angel 2009-01-15 15:48:05 UTC
can you test this with the version in rawhide? the zip error should be fixed.

Comment 2 James Ralston 2009-01-15 17:41:20 UTC
The version in Rawhide (java-1.6.0-openjdk-1.6.0.0-8.b14.fc11) behaves exactly the same way.

Comment 3 Lillian Angel 2009-01-15 17:51:50 UTC
thanks. do you have a test case?

Comment 4 James Ralston 2009-01-15 19:35:45 UTC
Not a public one, no. (The application we're having difficulty running is the Sun ILOM Remote Console application, which connects to the management interfaces on our Sun servers.)

However, if you could point me at some sort of lightweight JNLP demo application, I could build you a test case (by downloading it and putting it on a misconfigured HTTPS server). Do you know of anything that would fit the bill?

Comment 5 Jason Tibbitts 2009-05-22 16:54:14 UTC
I believe that I may be seeing this as well (bug 502225), and I can provide a test case (not a public one, but I can provide a hostname and login info privately if there's any chance of getting this fixed).

Comment 6 Deepak Bhole 2009-05-22 17:59:15 UTC
I have fixed this upstream. It will be there in the next OpenJDK update in F10 (tentatively scheduled 1-2 weeks from now).

Comment 7 Fedora Update System 2009-05-30 14:15:56 UTC
java-1.6.0-openjdk-1.6.0.0-18.b16.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-18.b16.fc10

Comment 8 Fedora Update System 2009-05-30 14:16:55 UTC
java-1.6.0-openjdk-1.6.0.0-22.b16.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-22.b16.fc11

Comment 9 Fedora Update System 2009-06-02 14:22:38 UTC
java-1.6.0-openjdk-1.6.0.0-22.b16.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Fedora Update System 2009-06-02 14:30:16 UTC
java-1.6.0-openjdk-1.6.0.0-18.b16.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Jason Tibbitts 2009-06-25 02:13:49 UTC
*** Bug 502225 has been marked as a duplicate of this bug. ***

Comment 12 Jason Tibbitts 2009-06-25 02:29:43 UTC
I just wanted to note that, once I work around bug 507870, I find that the the problem persists with java-1.6.0-openjdk-1.6.0.0-22.b16.fc11.x86_64.  The backtrace is unchanged from the one in the original comment.

Again, if there's any assistance I can provide, please let me know.  I can privately provide access to the failing application.

Comment 13 Martin Jürgens 2009-09-13 20:11:40 UTC
same problem on both x86_64 and i586. test case here: http://www.geogebra.org/webstart/geogebra.jnlp java-1.6.0-openjdk-1.6.0.0-27.b16.fc11.x86_64

i removed ~/.netx and ~/.netxrc

Comment 14 nadia80 2012-01-02 15:26:52 UTC
Hello,

I have the same problem with OpenJdk IcedTea6 1.7.4 rhel-1.21.b17.el6-x86_64.
In fact, I can't use SSL communication when launching javaws application. 
No explicit error is shown.
The same application can be launched with Sun JDK 1.6.0_30.

Thank you,

Comment 15 Deepak Bhole 2012-01-17 20:22:10 UTC
(In reply to comment #14)
> Hello,
> 
> I have the same problem with OpenJdk IcedTea6 1.7.4 rhel-1.21.b17.el6-x86_64.
> In fact, I can't use SSL communication when launching javaws application. 
> No explicit error is shown.
> The same application can be launched with Sun JDK 1.6.0_30.
> 
> Thank you,

Hi Nadia,

IcedTea6 1.7.4 is no longer supported upstream. The latest version of IcedTea6 in RHEL is 1.10.x and icedtea-web is at 1.1.x. Please upgrade to those -- this should be fixed there.


Note You need to log in before you can comment on or make changes to this bug.