So if you try to use Java to access something over HTTPS you'll get a security exception. For example, if you want to run Clojure using the excellent boot build too, the first time you try "$ boot repl" on either WRLinux/Gateway or Yocto/Edison, you’re going to get an exception along the lines of:
Exception in thread "main" javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
The problem is that although both systems ship with a large set of ca certificates, as well as preinstalled OpenJDK 1.8, the latter is not configured to use the former out of the box. Since I virtually never have to deal with this sort of thing it took me a couple of hours to figure out what the problem was and how to fix it. All you have to do is create a Java “trust store” by running a Java utility calledkeytoolonce for each certificate you want to add to the trust store. (A trust store is analogous to a key store; the latter is where you keep your keys, the former is where you keep public certificates of trust; if you’re a glutton for punishment take a look at Configuring Java CAPS for SSL Support.)
Here’s what you need to know to make sense of that:
- Java is installed at /usr/lib64/jvm (WRLinux on the Gateway), or /usr/lib/jvm (Yocto on Edison)
- The standard place for the Java truststore is $JAVA_HOME/jre/lib/security/cacerts. Note that cacerts is a file, not a directory. You create it with
- keytool
- keytool is located in $JAVA_HOME/jre/bin
- The certificates are in /etc/ssl/certs, which is a directory containing soft links to /usr/share/ca-certificates
Now you just need something to save you the drudgery on installing everything in /etc/ssl/certs into the Java trust store, since keytool must be given an individual file rather than a directory of files as input. Fortunately, somebody already wrote that script for us. You can find it at Introduction to OpenJDK in the subsection Install or update the JRE Certificate Authority Certificates (cacerts) file. I just copied that to ~/bin/mkcacerts, chmodded it to make it executable, and then created a one-time helper:
#!/bin/sh
# certs.sh # use this for Yocto/Edison: # LIB=lib # use this for WRLinux/Gateway LIB=lib64 if [ -f /usr/$LIB/jvm/java-8-openjdk/jre/lib/security/cacerts ]; then mv /usr/$LIB/jvm/java-8-openjdk/jre/lib/security/cacerts \ /usr/$LIB/jvm/java-8-openjdk/jre/lib/security/cacerts.bak fi # if you have a ca-certificates.crt file, use this: # -f "/etc/ssl/certs/ca-certificates.crt" # otherwise use # -d "/etc/ssl/certs/" ./mkcacerts \ -d "/etc/ssl/certs/" \ -k "/usr/$LIB/jvm/java-8-openjdk/bin/keytool" \ -s "/usr/bin/openssl" \ -o "/usr/$LIB/jvm/java-8-openjdk/jre/lib/security/cacerts"
There is one tricky bit: notice the "-d" parameter in the script above. Use that if /etc/ssl/certs contains certificates but no "ca-certificates.crt" - this was the case in earlier versions of the Edison. But if you find /etc/ssl/certs/ca-certificates.crt, then replace that line as noted in the comment.
Now cd to ~/bin and run $ ./certs.sh. You'll see a bunch of alarming-looking output as it churns through the certificates, adding them to the Java truststore (cacerts file). It takes a while, but once it's done you should be good to go with Java and HTTPS.