Deepak- can you comment on this? Was this fixed upstream?

There are a set of similar issues, all caused by lack of a UI for accepting https certificates -- I think that might be the problem here too. Work on this is ongoing upstream, and should be done really soon. I'll add a comment to this bug once it is fixed.

Should be fixed in java-1.6.0-openjdk-1.6.0.0-9.b14.fc10

Still getting the following with the latest openjdk:

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:101)
  at net.sourceforge.jnlp.tools.JarSigner.verifyJar(JarSigner.java:245)
  at net.sourceforge.jnlp.tools.JarSigner.verifyJars(JarSigner.java:220)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.verifyJars(JNLPClassLoader.java:660)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:330)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:161)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:218)
  at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:445)
  at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:418)
  at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:597)
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:101)
  at net.sourceforge.jnlp.tools.JarSigner.verifyJar(JarSigner.java:245)
  at net.sourceforge.jnlp.tools.JarSigner.verifyJars(JarSigner.java:220)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.verifyJars(JNLPClassLoader.java:660)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:330)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:161)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:218)
  at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:445)
  at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:418)
  at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:597)
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet.
  at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:472)
  at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:418)
  at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:597)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: A fatal error occurred while trying to verify jars.
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:336)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:161)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:218)
  at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:445)
  ... 2 more
Caused by:
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: A fatal error occurred while trying to verify jars.
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:336)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:161)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:218)
  at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:445)
  at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:418)
  at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:597)
java.lang.NullPointerException
  at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:97)
  at sun.applet.AppletPanel.run(AppletPanel.java:380)
  at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
  at sun.applet.AppletPanel.run(AppletPanel.java:430)
  at java.lang.Thread.run(Thread.java:636)

$ rpm -q java-1.6.0-openjdk
java-1.6.0-openjdk-1.6.0.0-9.b14.fc10.i386

I should note that at least now the plugin prompts me if I want to allow the applet to be trusted and run, but once I answer yes to this, the above errors appear in the terminal and the applet doesn't start correctly.

Anyone out there actually have success with this?

Can try again after clearing the cache? To clear the cache, run 'rm -rf ~/.icedteaplugin/cache' under your normal username.

If the problem still persists after that:

Please run firefox from command-line as 'ICEDTEAPLUGIN_DEBUG=true firefox' and post the output, and the /tmp/java.std* files that are created after trying to load the site.

Additionally, please also post the output of 'find ~/.icedteaplugin/cache -type f '

Sorry that the latest update doesn't fix the problem.. without access to a reproducible test case, I was guessing that https was the problem.. however it doesn't seem to be :(

Created attachment 332228 [details]
Iced Tea debug output from Juninper connection attempt.

Created attachment 332229 [details]
Firefox standard output from Juniper connection attempt

No worries, this seems to be a fun one to track down!  Attached the results as requested and here's the contents of the cache directory:

$ find ~/.icedteaplugin/ -type f
/home/rayvd/.icedteaplugin/cache/https/connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar
/home/rayvd/.icedteaplugin/cache/https/connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar.info

Hmm, so it looks like it did try to download the jar file... Can you please post output of 

ls -l /home/rayvd/.icedteaplugin/cache/https/connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar

and 

file /home/rayvd/.icedteaplugin/cache/https/connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar

connectdev.domain.com being replaced with the appropriate domain ofcourse!

$ ls -l /home/rayvd/.icedteaplugin/cache/https/connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar
-rw-rw-r-- 1 rayvd rayvd 4784 2009-02-17 07:31 /home/rayvd/.icedteaplugin/cache/https/connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar

[rayvd@tinyox ~]$ file /home/rayvd/.icedteaplugin/cache/https/connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar
/home/rayvd/.icedteaplugin/cache/https/connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar: ASCII HTML document text, with very long lines

Sorry for the word wrap.

Interesting.  HTML file?  Examining the content it appears to be the HTML login page...

Also, let me know if you'd prefer I open an SR and another (private) bz for this against RHEL5 openjdk.  Might be able to provide more useful output or other more detailed information.

Yep, that HTML file certainly explains the exception. The question though, is why. Can you try these  commands and paste the output:

wget https://connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar
ls -l ncLinuxLauncher.jar
file ncLinuxLauncher.jar
rm -f ncLinuxLauncher.jar

wget -U "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.2) Gecko/2008092318 Fedora/3.0.2-1.fc9 Firefox/3.0.2" https://connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar
ls -l ncLinuxLauncher.jar
file ncLinuxLauncher.jar
rm -f ncLinuxLauncher.jar

I am wondering if the server is refusing to serve the jar file to non browser clients. The above should clarify that..

https://bugzilla.redhat.com/show_bug.cgi?id=473141 looks like the same issue.

Actually, I am pretty sure 473141 was https related and is fixed now. I was provided with a test site similar to that bug and it works with the latest version.

(In reply to comment #13)
> Yep, that HTML file certainly explains the exception. The question though, is
> why. Can you try these  commands and paste the output:
> 
> wget https://connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar
> ls -l ncLinuxLauncher.jar
> file ncLinuxLauncher.jar
> rm -f ncLinuxLauncher.jar
> 
> wget -U "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.2) Gecko/2008092318
> Fedora/3.0.2-1.fc9 Firefox/3.0.2"
> https://connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar
> ls -l ncLinuxLauncher.jar
> file ncLinuxLauncher.jar
> rm -f ncLinuxLauncher.jar
> 
> I am wondering if the server is refusing to serve the jar file to non browser
> clients. The above should clarify that..

Neither download the .jar file.  Both fire up the welcome.cgi page containing the authentication form.

Maybe the plugin isn't passing along the cookie information required to identify the session correctly?  The server assumes an unauthenticated request and this is why we're getting HTML output...

I might be able to verify this with wireshark if needed.....

The plugin definitely doesn't pass the cookie information. I am not sure if the Sun one does either.. in any case, can you try downloading the file by entering the URL in firefox? Atleast that will rule out a 404/auto redirect....

It works from Firefox if I've correctly authenticated (hmm, I wonder if I save the .jar file to that cache directory if I could then connect successfully with icedtea...)

It gives me the login page from Firefox if I have not authenticated correctly first (likely the same welcome.cgi we see from wget).

Not sure how the Sun plugin handles this except to say that it is able to load the .jar up somehow.  The whole login process does look slightly different.  The Sun plugin seems to stick to the same page whereas the OpenJDK one seems to jump over to another blank page first.

I'm going to look into getting my hands on the crt file for the https connection and see if I can get wireshark to peer inside the connection and determine what's different about the requests.

Would an ogg via istanbul of the login process with Sun vs OpenJDK be helpful to you?

Thanks much.

I did snag a capture via istanbul comparing logins via Sun vs OpenJDK plugin.  If you're interested, I can email it to you directly.

Oh yes, please! It'd be very helpful to see the wire data if cookies/authentication is happening with the Sun plugin and not ours. Thanks.

*** Bug 482943 has been marked as a duplicate of this bug. ***

Well, couldn't get the private key file I needed from work, so, after many trials and tribulations setting up an Apache proxy and the correct cipher settings to allow Wireshark to actually decrypt things (BTW, Java and Firefox appear to use different DNS resolving mechanisms :), I did manage to grab two sessions -- one with Sun's plugin and another with IcedTea's.

Sun's definitely is sending cookie information, and in response gets back the proper .jar file.  IcedTea does not and instead gets a 302 response that redirects back to the welcome page.

I will email these files to your personal email account.  Probably nothing too sensitive in them except for some old expired session id's, but just to be on the prudent side.

Let me know if you need anything else.

PS, the following snippet is inside the applet block on the page that kicks off the client.

<script language="JavaScript">
  document.write(' <param name=cookies value=\"' + document.cookie + '\">');
</script>

(In reply to comment #22)
> Well, couldn't get the private key file I needed from work, so, after many
> trials and tribulations setting up an Apache proxy and the correct cipher
> settings to allow Wireshark to actually decrypt things (BTW, Java and Firefox
> appear to use different DNS resolving mechanisms :), I did manage to grab two
> sessions -- one with Sun's plugin and another with IcedTea's.


If and when you have the time, it would be very helpful and time efficient if you could post about exactly what you needed to do to get the Juniper Network Connect + Apache proxy + Wireshark packet capture set up usefully. I am doing some research into how difficult it'd be to implement a pure OSS solution to connecting to Juniper SSL VPNs. David Woodhouse has done some interesting things[1] for Cisco AnyConnect VPNs, resulting in NetworkManager-openconnect being available in Fedora. I wonder if any of that work is portable to Juniper. Thanks!

[1] http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/2008-September/002577.html

Posted an initial blog entry here[1] describing what I did.  Hopefully I didn't miss anything. :-)

[1] http://www.bludgeon.org/~rayvd/blog/fedora/juniper.html

I can now connect successfully with the scratch build of openjdk that Deepak built today.

java-1.6.0-openjdk-plugin-1.6.0.0-10.b14.1.fc10.i386

Connected to my work VPN as we speak!  Thanks much Deepak.  How soon can we expect this to show up in RHEL?

Thanks again.

is there a way to get that build from somewhere to test my bug (dupe of this one) as well ?

For anyone that may want the fix right away, here is a tentative build with the latest version of the plugin, that resolves this issue. Thanks to Ray for verifying!

http://koji.fedoraproject.org/koji/taskinfo?taskID=1149662

I will close this issue when we push out an official build with the changes.

this actually makes the situation worse for me - now i cannot even login

is there any info you'd like ?

Should we handle that in this bug or in my old bug ?

(In reply to comment #29)
> this actually makes the situation worse for me - now i cannot even login
> 
> is there any info you'd like ?
> 
> Should we handle that in this bug or in my old bug ?

You can't log in via the webpage or.... ?  Maybe the old .jar file is still cached.  Make sure and rm -rf ~/.icedteaplugin/cache first.

i cannot login via the homepage 

https://auth1.forsakringskassan.se/necs/bidlogon.jsp?TARGET=https://gate1.forsakringskassan.se/portal2/

even after removing the icedteaplugin cache

i just get a grey box whereas i would normally get a login prompt

please note that all my problems are in detail described in https://bugzilla.redhat.com/show_bug.cgi?id=482943

rather than here

Hmm, that is odd. According to the analysis on that bug, the problem was cookies not being sent by the plugin. I will reopen that bug and we can track it there.

By the way, the above build is a scratch build, so it may be gone any time. We are working on a new F-10/Rawhide update. In the mean time, Gary Benson from here at RedHat has graciously offered to host the files. They are located here.

http://gbenson.net/dbhole/

checksums are as follows:

1f7ed0ae0566ed92218365c9c33a5971  java-1.6.0-openjdk-1.6.0.0-10.b14.1.fc10.i386.rpm
cf19a27fc0e4d6feb564d8cdc4b0bd0e  java-1.6.0-openjdk-1.6.0.0-10.b14.1.fc10.src.rpm
608dc1a3a09fd48027baf0366e24cf30  java-1.6.0-openjdk-1.6.0.0-10.b14.1.fc10.x86_64.rpm
38347f2002508e47e87b39f86db58c2d  java-1.6.0-openjdk-debuginfo-1.6.0.0-10.b14.1.fc10.i386.rpm
803906a8122a8bd5133be0909b0ae509  java-1.6.0-openjdk-debuginfo-1.6.0.0-10.b14.1.fc10.x86_64.rpm
6ddaae595d8cae08e424dfe8b7d48745  java-1.6.0-openjdk-demo-1.6.0.0-10.b14.1.fc10.i386.rpm
ef258135088a92507f76024eb6f17309  java-1.6.0-openjdk-demo-1.6.0.0-10.b14.1.fc10.x86_64.rpm
f0ebd2907bb143e0fe2846fd107f46e1  java-1.6.0-openjdk-devel-1.6.0.0-10.b14.1.fc10.i386.rpm
2e2d7124d31d45d3cd085a4fbad49d35  java-1.6.0-openjdk-devel-1.6.0.0-10.b14.1.fc10.x86_64.rpm
32655a7f1607f321675f49b98945ff9f  java-1.6.0-openjdk-javadoc-1.6.0.0-10.b14.1.fc10.i386.rpm
a8c95428c6f277e783c8abb8301d9ce1  java-1.6.0-openjdk-javadoc-1.6.0.0-10.b14.1.fc10.x86_64.rpm
103c7c511dff60eba17320cdd3751081  java-1.6.0-openjdk-plugin-1.6.0.0-10.b14.1.fc10.i386.rpm
6c0e7dbe0c773864f182f085822d44a2  java-1.6.0-openjdk-plugin-1.6.0.0-10.b14.1.fc10.x86_64.rpm
92d01ac954cb5db29e95e47fac9b477b  java-1.6.0-openjdk-src-1.6.0.0-10.b14.1.fc10.i386.rpm
13914fd3535a03aa9ac396c1c2c7010e  java-1.6.0-openjdk-src-1.6.0.0-10.b14.1.fc10.x86_64.rpm

fix will be in rawhide within the next couple of days

Thanks guys for your work on this.

Will this be slated for RHEL 5 as well?  Errata to 5.3 or targeted for 5.4?

Would you recommend I open an SR?

the openjdk plugin is not available in RHEL.

(In reply to comment #37)
> the openjdk plugin is not available in RHEL.

My mistake.  It's in EPEL.  I'll poke the EPEL maintainer.

Are you guys planning to release this for Fedora 10 officially?

No update for F-10 has been discussed yet. Possibly when we release IcedTea6-1.5. No timeframe either.

ehm seeing my problem again

java-1.6.0-openjdk-plugin-1.6.0.0-15.b14.fc10.i386
java-1.6.0-openjdk-1.6.0.0-15.b14.fc10.i386


should i try to get a trace or si this the wrong version - is thera any way to get hold of a working build again ?

brg Pontus

This hasn't been updated in F-10 yet. Check rawhide. It will be in the next release.

ahh sweet (mee smacking forehead after finding old builds on other computer lying around at home)

sorry for the fuzz

Can you tell me if a fix for this will be in updates-testing (or is there already)? I am affected by this bug and am very interested to see a fix. If not in updates testing is there a time-frame for a fix going to either updates-testing or updates?

Thanks

The openjdk b14.1 RPMS mentioned above in comments for this bug don't work for me. My company has a Juniper netscreen VPN box. It works perfectly with SUN JRE. With the above RPMS, I get a dialog box asking about running the appet/trusting the publisher. I answer yes always for all the dialogs. It starts the applet, but then quits saying "Config failed".

I tried F11 with openjdk 22.b16 update. No luck.

I would be glad to provide any debugging data.