One of our clients introduced a new LDAP server for authentication. Like a good partner, they implemented it in the test environment, found it did not work and alerted us to the problem. They also informed us the problem would be the new Thawte Root CA was not implemented on many operating systems and applications. Indeed our research pointed out Sun/Oracle had not implemented the Root CA in their list of valid ones.

Normally we do not add root CAs. A specific case which comes to mind is another client “bought” a free SSL certificate for higher education from a place in Barcelona. In this case, we decided to go ahead and add it. However, we wanted to do so in a supported manner, so I opened a ticket with Blackboard.

The recommendation was to use the keytool to apply the new Root CA. (I would not do this without having an open ticket with Blackboard as if anything goes wrong, then at least you can get faster support.) After a couple modifications of what they gave me, the keytool command worked. Namely, the cacerts file is installed with read only permission, so it needs write to be edited. Plus the -keypass  The process to use if we need to do this again will be:

# Navigate to where the root cert is stored.
cd ${JAVA_HOME}
cd ../lib/security/
# Copy the existing cacerts file to a backup in case we need to revert.
cp cacerts cacerts.bak
# Copy the existing cacerts file to a working copy so not affect running processes while editing.
cp cacerts cacerts.new
# Java sets permissions on the file to 444. Change to 644 to edit.
chmod 644 cacerts.new && ls -l cacerts*
# Set the variable for the name of the file to import.
NEWCERT=newthawteroot1
# Run the import keytool. Will ask for password. Ask the system admin or try the Java default.
${JAVA_HOME}/keytool -import -trustcacerts -alias ${NEWCERT} -file ${NEWCERT}.pem -keystore cacerts.new
# Verify change took.
${JAVA_HOME}/keytool -list -v -keystore cacerts.new | grep -A 10 ${NEWCERT}
chmod 444 cacerts.new && ls -l cacerts*
chmod 644 cacerts && cp cacerts.new cacerts && chmod 444 cacerts && ls -l cacerts*
# Another verify but on  cacerts would not hurt to make sure it has the new root ca.

At this point I asked for the institution test on the node where I made the change. (It happens that test cluster has a single node in a special pool. I had made this change on that node. It also meant other institutions testing on that cluster were not affected.) We still want to verify introducing this does not affect others using LDAP. I don’t think that it will, but that never comes across to people as reliable when something completely unexpected causes a problem.

Now to write a script to push this change to the other 180 nodes. Should be easy enough as I copied the new cacerts to our mounted file system. I just need a script to navigate to the where the file is stored, make a backup, chmod, copy, chmod, and verify.