Brian,
On 9/13/23 23:25, Brian Wolfe wrote:
The PKCS12 is the industry standard keystore format. Your mac should be
creating it in that version. You should get familiar using the pkcs12. Its
not difficult to set it up. keytool and openssl support pkcs12 and have for
some time now. Its possible your older keystores are of the storetype JKS
or JCEKS, JKS used to be the default I think back in Java 6. Anything newer
should throw a warning telling you the industry standard is pkcs12. But you
can still open older formats by specifying the "--storetype" option. Your
getting that error because you probably didn't tell it what kind it is and
its default assumption is wrong.
Using a keystore is much better for managing your keys than using PEM
files.
Why?
It's best practice to have seperate stores for keys and for trust.
+1, and using files in PEM format do not preclude this.
by default java has the "cacerts" file for establishing trust.
True, but not terribly relevant.
-chris
On Wed, Sep 13, 2023 at 8:16 PM James H. H. Lampert
<jam...@touchtonecorp.com.invalid> wrote:
Java Keystores work. And I don't find them especially difficult to work
with (other than new formats not being backward-compatible with older
JVMs, and as one who has made a comfortable living banging out code for
IBM Midrange boxes for over a quarter century, I am quite familiar with
a much worse variation on that theme, namely, unless you explicitly set
the TGTRLS parameter (and have the appropriate previous version compiler
installed, and don't need to go back more than it will let you), your
programs will not even *restore* onto a prior release system.
And the one time I attempted to get anything other than a Java Keystore
to work in Tomcat, on an IBM Midrange box, I failed miserably.
Putting shell-script wrappers around two different versions of keytool
on my work Mac, so that "keytool" launches the Java 8 version, and
"keytool-default" launches the default version (in the unlikely event
that I'd ever need it) was a relatively simple exercise.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
