Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)

Ladies and Gentlemen of Both Lists:

Last Friday evening, I ran into a problem updating SSL/TLS keystores on two customer boxes, and spent three hours yesterday, finding the cause, doping out a way to salvage the certs they'd paid for, and doping out a solution to keep it from happening in the future.

It seems that with the new keystores (generated on my Mac, initially created with Keytool, and then maintained with Keystore Explorer), they were getting:

> Throwable occurred: java.io.IOException: Invalid keystore format
> at com.ibm.crypto.provider.JavaKeyStore.engineLoad(Unknown Source)
> at java.security.KeyStore.load(KeyStore.java:414)

I put them back on their old keystores, and cycled Tomcat again, to get them back up, and then spent three hours working the problem yesterday (Sunday) afternoon.

It turns out that the default keytool on my new Mac is the one from Java 17. And the customer boxes are running Tomcat under much older JVMs, because there's always a significant time lag before any given JVM makes it to an IBM Midrange box.

So I was able to salvage one of the certs (and its CA reply, and its chain) by moving the cert to a keystore generated on my *old* Mac (with Java 8 as the default JVM), and then re-signing and re-chaining it in KSE. And I tested the KS on our V6 box, to make *sure* it worked.

I then looked for a way, since my new Mac *has* a Java 8 JVM (it's just not the default), to conveniently use that JVM's Keytool, and came up with a wrapper BASH script to do the job. I tested the wrapper script by using it to generate their new keystore.

Key takeaway (no pun intended) here: if you get an "Invalid keystore format" in Tomcat (or presumably anything else that uses Java Keystores), when generating a keystore on one box for use on another, *look for a difference in JVM.*

--
JHHL