How to overcome a certain type of "Start: applet not initialized" error with an Ubuntu + Firefox3 + OpenJDK combo

I'm testing Ubuntu 8.04 at my working place before we deploy it as a terminal server for our colleagues.
The server has a single Intel Core2 Quad CPU and Ubuntu was installed using the amd64 architecture.
Up til now I saw no drawback from choosing the amd64 arch., but Sun's Java plugin came in the picture just to cause me some headache.

As I've found out: Sun does not provide a 64 bit version of the Java plugin, however it is needed for some (mainly the Mozilla based ones like Firefox) browsers to be able to run Java applets. At this point you've a couple of options left:
  • You can remove the 64 bit version of Firefox (that is part of the distro) and install a 32 bit version. This way you can use the 32 bit version of the Java plugin from the i386 arch. All this is well described here.
  • If you don't like the idea of a mixed distro (some 64 bit apps and some 32 bit apps), you can reinstall the whole server using the i386 arch. Smile
  • Or you can choose to try an alternative JRE instead of Sun's. There's OpenJDK which is the default JRE/JDK on Ubuntu. You can install the necessary Java plugin with the icedtea-gcjwebplugin package.
I didn't like the first two ideas so I went for OpenJDK. It's still at its infancy (Sun has released Java's source only a year ago or so), but eventually it'll prevail. Smile The "official" Java-applet testing page was loading nicely, no problem there. However my bank's online interface failed. Sad There was no Java console popping up with some fancy Java exception (error message) ... the only sign of a problem was that the applet obviously failed to start and Firefox displayed in the status bar the following: "Start: applet not initialized".

A little bit of googling revealed to me that the standard output (and error) of Java applets appears on the standard output (and error) of the Firefox process. All you have to do is to start Firefox from a terminal instead of the launcher icon. This way I could take a look at what was going on. The applet threw the following expections:
  PIPE: appletviewer wrote: status load: class ebank.applet.MainApplet not found.
load: class ebank.applet.MainApplet not found.
java.lang.ClassNotFoundException: ebank.applet.MainApplet
        at sun.applet.AppletClassLoader.findClass(
        at java.lang.ClassLoader.loadClass(
        at sun.applet.AppletClassLoader.loadClass(
        at java.lang.ClassLoader.loadClass(
        at sun.applet.AppletClassLoader.loadCode(
        at sun.applet.AppletPanel.createApplet(
        at sun.applet.AppletPanel.runLoader(
Caused by: PKIX path building failed: unable to find valid certification path to requested target

Okay ... so it's a certificate problem. Let's see. A bit more googling revealed that Java applets use the same keystore as any other Java application. Thus one cannot add the certificate of the particular banking site (server) to a user's own keystore, there's no such thing. You've to add that certificate to the server's global keystore. On Ubuntu this store happens to be in the /etc/ssl/certs directory. It is maintained by the ca-certificates package and the configuration is stored in the /etc/ca-certificates.conf file. However you should not mess with that file, but use the dpkg-reconfigure ca-certificates command. The certficiates must be put somewhere in the /usr/share/ca-certificates directory and the .crt extension must be used. If your certificate is in place, execute the dpkg-reconfigure ca-certificates command and enable the certificate that you just installed. This will generate the various symlinks in the /etc/ssl/certs directory.

Now start Firefox again (still from the terminal) and load the page with the applet again. This time the applet should proceed successfully.

One little detail I missed to mention: you can fetch the certificate of the server by loading the https URL of the banking website, double-click on the lock icon in the status bar of Firefox, select "View Certificate", then the "Details" tab and click "Export".

P.S.: the applet of my bank was damned slow with OpenJDK. Sad Sun's JRE was not a speeder either, but still a lot faster.
P.S.2: Sun's JRE+plugin combo handles SSL certificates a bit more sophisticatedly ... it pops up a dialog asking whether you trust the certificate's CA or not. You can even mark the certificate to be always trusted with the "Always" checkbox. Imho OpenJDK should adopt a similiar strategy.
P.S.3: as it happens, I've just stumbled on the official Ubuntu Wiki page describing the handling of OpenSSL certificates in Ubuntu. Take a look at the "Using PKCS#12 Certificates in Client Applications" section and the "Importing a Certificate into the System-Wide Certificate Authority Database" sub-section.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Help me, please!

Hi müzso, how did you do to import using your ca manager?

Re: help me, please!

What do you mean by "ca manager"? I've described in my post quite detailed how to add a certificate to the server-wide certificate repository. Shock

ca manager, i mean,

ca manager, i mean, certificate authority manager. I use suse (kde) but i guess that every distro has some kind of ca manager, right? What did you do exactly? You exported the certificate in the form of a .crt or .pem (or converted first into one another), then put somewhere in /usr/share/ca-certificates, although my distro doesn't have this directory. do you have a clue for me? sorry for bothering you like a n00b (err...I am), but it seems like you are my only hope, this whole applet thing is annoying me very much=(. Is there some way i can do it manually, just adding them to /etc/ssl and using openssl to generate the symbolic links?thanks in advance.

Re: ca manager

Oops, I must have missed your comment. Sorry for the late reply. Sad
Unfortunately I've no idea how SUSE manages certificates (never been a SUSE user), thus I cannot point you to the right direction.

Don't worry

Hi müzso, that's ok ;P. I've decided to wait for a 64-bit version after long search for a temporary solution and eventually Sun released it. Now it works like a charm. Thanks for your attention anyway.

Re: Don't worry

Glad to hear that Sun finally got to release a 64bit JRE. It took them long enough.
It seems that most companies are not in a hurry to jump on the 64bit wagon.
Eg. Mozilla has still not announced an official statement about the first 64bit release of Firefox (there're unofficial 64 bit builds though) and a 64bit Flash player has not even been mentioned by Adobe yet. I'm curious though ... Apple just released Snow Leopard with a 64 bit Safari. I wonder whether it has a 64 bit Flash player or it still uses the 32 bit version. I doubt that a 64 bit browser supports 32 bit plugins ... but who knows these days. Smile

Update: I googled a bit and found this post with a screenshot of Activity Monitor (the Mac OS X equivalent of the Task Manager of Windows) of Snow Leopard showing that the 64 bit Safari is indeed running a 32 bit Flash player plugin. Sad

64-bit flash player

I think Adobe released a 64-bit version of flash player last year. I had some problems with flash content sometimes (it would crash, turn all flash related components into a gray box and I had to restart the browser) but now I use their 64-bit version and everything just works fine (in my system it's under the name which means no more wrapper hell \o/).

Syndicate content