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.
- 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
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.
The "official" Java-applet testing page
was loading nicely, no problem there. However my bank's online interface failed.
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.
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: 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
package and the configuration is stored in the
file. However you should not mess with that file, but use the
command. The certficiates must be put somewhere in the
directory and the
extension must be used. If your certificate is in place, execute the
command and enable the certificate that you just installed. This will generate the various symlinks in the
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.
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.