Bug 846763 - Java applets do not run when both the applet spec in html and the jar come over https
Java applets do not run when both the applet spec in html and the jar come ov...
Product: Fedora
Classification: Fedora
Component: java-1.6.0-openjdk (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Deepak Bhole
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-08-08 11:47 EDT by Albert Flügel
Modified: 2013-07-31 19:31 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-07-31 19:31:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Java applet to show the problem (1.07 KB, application/x-gzip)
2012-08-08 11:47 EDT, Albert Flügel
no flags Details

  None (edit)
Description Albert Flügel 2012-08-08 11:47:34 EDT
Created attachment 603063 [details]
Java applet to show the problem

Description of problem:
When a https delivered page specifies, that a java applet should be run
and the program (jar container) is also coming over https, an exception
JAR https://my.server.domain.com/HelloWorld.jar not found

* this happens only on Fedora 17 with Firefox 14.0.1
* it did not happen on any earlier Fedora version or any Redhat Enterprise Linux or any earlier Firefox
* it does NOT happen when the JAR file comes over http (plaintext)
* it does neither happen, when there is notable network delay between firefox and the server
* The web server delivering the data does not matter
* Java version is 1.7.0_05-icedtea
* it breaks my weblogin (sourceforge.net/projects/weblogin)

Version-Release number of selected component (if applicable):
firefox 14.0.1-1.fc17
Java version is 1.7.0_05-icedtea

How reproducible:
use the attached file and

Steps to Reproduce:
1. unpack the attached file into a directory
2. run make (with gcj run: make JC="gcj -C" JAR=fastjar )
3. check, that the built HelloWorld.jar works: java -jar HelloWorld.jar
4. Put HelloWorld.html and HelloWorld.jar into a directory on a webserver, that is close to your fc17 client
5. Point the firefox-14.0.1-1.fc17 to download the HelloWorld.html over http
5a. It is helpful to run firefox from the command line, so one can see the Java output
6. Verify the applet shows up
7. Have firefox download the same file over https
Actual results:
over https one gets 
JAR https://my.server.domain.com/HelloWorld.jar not found

Expected results:
applet runs like over http

Additional info:
Feel free to modify the HelloWorld.html to download over http, so that
the HelloWorld.html comes over http and the HelloWorld.jar comes over
https. This won't work either, but the other way round it works.
If you have a software network delay line, put them between the firefox
client and the server. It is likely to work this way, but i don't know
Comment 1 Martin Stransky 2012-08-09 07:56:37 EDT
Can you please test it with firefox binary version from mozilla.org?
Comment 2 Albert Flügel 2012-08-09 09:40:50 EDT
Downloaded 14.0.1 (and openjdk 1.7.0-05) and searched tons of web pages how to enable java in it. Nothing seems appropriate. With each and every firefox version it must be done differently and it's even different for 32 and 64 bit *sigh*. What symlink do i have to set where to what ?
Comment 3 Martin Stransky 2012-08-10 04:52:05 EDT
Okay, and can you test which version is broken? Does it work with Firefox 10,11,12,13 for instance? You can download them from koji - http://koji.fedoraproject.org/koji/
Comment 4 Albert Flügel 2012-08-10 10:27:43 EDT
Sorry i just need a hint.
I'll gladly test whatever version, but i need to know how to enable java applets in firefox 14 (or whatever version). The binary to download from mozilla is a 32 bit program and my fedora instance is a 64 bit. All libraries and java is in place also as 32 bit. I'm pretty sure, that there is not much to do to make java applets work. I just don't find it anywhere.
Thanks for any hint.
Comment 5 Martin Stransky 2012-08-10 11:15:53 EDT
NO, you don't need to set up anything. You can download the old Fedora Firefox versions directly from koji (http://koji.fedoraproject.org/koji/). You can find the packages here:


Anyway, have it ever worked with any old Firefox version or not?
Comment 6 Albert Flügel 2012-08-11 05:07:27 EDT
Sorry, it takes a bit of time to test on the different systems during the leisure time ...

So what i found until now:
On Fedora 16 with firefox 12.1 it works and also with 14.0.1.
So i guess it has to do with the java version.
Who is downloading the jar file, the firefox or already the java machine ?
On the Fedora 16 host a java-1.6.0-openjdk is installed, on
the Fedora-17 it's 1.7.0 (what is said to be more secure ...).
I tried to put 1.7.0 in effect on
the Fedora-16 system. Deinstalling the 1.6.0 forcibly probably
breaks more things on this system and i still need this one,
so this is currently not an option for me.

This brought me to the idea, that it might actually be bound
to the SSL certificates. The servers, where it's working, have a
certificate from a CA. However, this CA is not an official one
and has a self signed root certificate (not signed by one of
those institutions, whose certificates are typically coming
with browsers or other SSL clients)
so neither the firefox nor java should initially trust them.
The server, where it's not working, has a self signed certificate,
so there's no chain of trust. However, this imo still does not
explain, why it might work with one server and not with another one.
I'll do more tests in this direction.
Comment 7 Albert Flügel 2012-08-11 06:34:17 EDT
Hm. On a server, where it failed, i created new
(still self signed) certificates. The others were
expired. Now it works. Seems, with the new java version
a problem with the certificate is not ignored, when
pressing "i understand the risks ..." when loading
the jar file. I'll try and check on the other server
and expect the same thing (will be able to do this Monday)
and report. So this is probably not a bug. However,
some hint in some release notes would be helpful.
Comment 8 Albert Flügel 2012-08-13 09:12:00 EDT
It seems definitely to be the expired SSL certificate, that is not
accepted anymore when downloading the jar file.

If you think, this change from the earlier behaviour is not a bug,
feel free to close this issue.

However, imo a clear error message would save tons of time.
Comment 9 Martin Stransky 2012-08-20 08:58:46 EDT
I guess it's a java issue, right? If not please reassign it back. Thanks!
Comment 10 Albert Flügel 2012-08-21 12:16:00 EDT
And there's another thing, that seems to have changed and
i don't know, if this is intended or just accidentially causing
personyears of additional efforts worldwide:
With the ARCHIVE of a APPLET specification it is no longer possible
to use a relative path but now the entire URL must be given, what
makes things less flexible and i'd like to avoid such code.
Comment 11 Deepak Bhole 2012-08-21 12:33:23 EDT
(In reply to comment #10)
> And there's another thing, that seems to have changed and
> i don't know, if this is intended or just accidentially causing
> personyears of additional efforts worldwide:
> With the ARCHIVE of a APPLET specification it is no longer possible
> to use a relative path but now the entire URL must be given, what
> makes things less flexible and i'd like to avoid such code.

This is definitely not intentional. Can you please post a test tag I can try? (no need for applet itself, I can stick in a dummy applet).

I just tried relative ARCHIVE path locally with the version in F17 and it works for me.
Comment 12 Albert Flügel 2012-08-21 14:18:06 EDT
Unbelievable. Now it works again. I spent hours to find out,
why i got again the message JAR <full-correct-url-to-the-jar> not found
from the jre.
Pasting the URL into the browser downloaded the jar without problem.
It drove me crazy, really. For a long time it works rock-solid and
then from one second to the other it does not work anymore and
strongly refuses to without any visible reason. Sorry for the effort.
Comment 13 Deepak Bhole 2012-08-21 14:23:22 EDT
Ah okay. NP.. glad it works again! :)
Comment 14 Albert Flügel 2012-08-21 23:17:11 EDT
The problem was also visible with the simple example attached with this report.

However, i'd really like to know, if the subject of (probably not only my)
interest is working elsewhere on F17. The weblogin is what it's about:
http://sourceforge.net/projects/weblogin .

Unfortunately, to test a bit of things must be done. I explain it here,
though i don't have any hope that someone will try.

* Download http://sourceforge.net/projects/afbackup/files/afbackup-3.5.8.tar.gz
  Build (not afbackup, but the contained) albiutils:
  * Put the file into your favourite rpm/SOURCES directory (on F17 it's
    /root/rpmbuild/SOURCES when installing SRPMs)
  * use the contained albiutils.spec.rh to build the installable RPM:
    rpmbuild -bb /path/to/albiutils.spec.rh
  * Install the created RPM. It contains a few things i often wonder how any
    admin can do without. anyway.
* Download the development status of weblogin:
  * Install it
  * build the package: rpmbuild -bb /root/rpmbuild/SPECS/weblogin.spec
  * install the package
    rpm -ivh /root/rpmbuild/RPMS/<arch>/weblogin-1.2.1-0.<arch>.rpm

Try to use it starting and connecting sessions via web:

If it really works: Does it really work ? Are you sure ?
(it's always such a mess to make it work on any new Linux Distro release.
But it's cool BTW, isn't it ?)

* If selinux is enabled, the service does not start. selinux must be
  configured to allow connections to the port (must rtfm how to do this)
* If you cannot connect, probably a firewall is active. So allow the
  port with iptables or disable the firewall
* Don't be surprised, that the geometry setting made on the session
  management page is ignored. This is subject to bug 847442
* To see Java error messages, run the firefox from the commandline.
  With firefox 10 or higher there is no Java console, so when starting
  via desktop they can't be seen.
Comment 15 Fedora End Of Life 2013-07-03 17:57:42 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 16 Fedora End Of Life 2013-07-31 19:31:33 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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