Today while working on the AASU Blackboard VISTA custom login page, I ran into an issue loading Java applets.
Apparently, Google Chrome checks your browser plug-ins to determine if they are out of date when you attempt to load content requiring them. Here’s a snippet from the Google Support Site about the bug feature:
To make sure you’re protected, whenever Google Chrome detects that a common plug-in on a page is out of date with a security vulnerability, a message will appear beneath the address bar notifying you that the plug-in has been blocked.
While this is a great feature, since it is an attempt to protect your computer from nefarious code, there are times that it just doesn’t work properly.
The situation I ran into is described on a chromium issue report. Basically, the Linux version of Oracle Java 7 is being seen as out-of-date, even though it is the most recent version available. When going into the Google Chrome plug-in preferences you may see the Java plug-in marked as disabled and showing the version number in red as well as a link to java.com to download a security update.
While Chrome does give you ability to run the plug-in each time it is used, this can rapidly become a pain in the rear. The checkbox labeled Always Allow also doesn’t seem to work.
So what to do? Well, you can either painstakingly click the Run this time button or you can run Google Chrome with a command line switch that turns off the plugin checking mechanism.
Being an intrepid sort that likes to live on the edge and dance where angels fear to tread, I chose to run with the checking mechanism turned off. To update the Ubuntu application launcher to make this easier, I edited the following file:
/usr/share/applications/google-chrome.desktop
sudo vi /usr/share/applications/google-chrome.desktop
Look for the first instance of a line starting with Exec and alter it to read as follows:
Exec=/opt/google/chrome/google-chrome --allow-outdated-plugins %U
After saving the file and restarting Google Chrome you will no longer be bothered by the annoying Java plug-in error warning. To verify this is working, you can enter the following on the command line:
ps ux | grep -v grep | grep allow-outdated-plugins
You should get back at least one result.
As a bonus, you can ensure that you are running the most recent version of Java (1.7.0_05 as of this writing) by doing the following on a command line:
java -version javac -version
You should see something like the following:
foreandy@foreandy-iMac:~$ java -version java version "1.7.0_05" Java(TM) SE Runtime Environment (build 1.7.0_05-b05) Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode) foreandy@foreandy-iMac:~$ javac -version javac 1.7.0_05
At work we run the WebCT Vista course management system by Blackboard.
Recently I was requested to figure out how to import the security certificate from the command line so that we could add this to the login script used for our campus computers. The main reason behind this was to eliminate the need for the user to have to manually agree to the security certificate when browsing to the CMS.
Normally when you want to create a Java keystore, you would use the keytool program located in
. If you run this program to import a certificate without specifying a location for the keystore it tries to create one named
in the user profile home directory.
However, when the JRE actually imports a certificate it doesn’t put it in this file. After some investigation, it turns out that the JRE imports certificates into a file named
which is located in the following directory
C:\Documents and Settings\USERNAME\Application Data\Sun\Java\Deployment\security\
In order to import a certificate into a keystore you need to vital pieces of information:
- the keystore name
- the keystore password
The problem here is that this keystore is being automatically created by the JRE. It turns out that this keystore has a password that is an empty string. What this means is that when you import a certificate you have to specify the password by using the storepass parameter with a value “”.
For example if the certificate that you want to import has a name and path of
the command to import the certificate for the user jdoe would be
keytool.exe -import -noprompt -keystore C:\Documents and Settings\jdoe\Application Data\Sun\Java\Deployment\security\trusted.certs -storepass “” -file c:\Blackboard.cer
Update 2008-04-09:
I have also found how to do this on Mac OS X. According to the developer documents, the JVM on Mac OS X uses the user’s default keychain to store this type of certificate instead of using a file-based keystore like the other OS.
In order to store the certificate in the user’s login keychain you can import it via the command line tool
that is installed on the OS.
The command to import this certificate from the command line is
certtool i path/to/cert/file k=~/Library/Keychains/login.keychain
If you want to have this happen at login for each user who might login, then you could implement this via a login hook. For more on this, take a gander at the article 301446 in the Apple knowledgebase.