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
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.
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.
java.lang.ClassNotFoundException: ebank.applet.MainApplet
at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:201)
at java.lang.ClassLoader.loadClass(ClassLoader.java:323)
at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:145)
at java.lang.ClassLoader.loadClass(ClassLoader.java:268)
at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:644)
at sun.applet.AppletPanel.createApplet(AppletPanel.java:798)
at sun.applet.AppletPanel.runLoader(AppletPanel.java:727)
at sun.applet.AppletPanel.run(AppletPanel.java:380)
at java.lang.Thread.run(Thread.java:636)
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
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1611)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:204)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:198)
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.
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.
Comments
Help me, please!
Re: help me, please!
ca manager, i mean,
Re: ca manager
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
Re: Don't worry
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.
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.
64-bit flash player