-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

All,

I've been writing a utility to scan a bunch of arbitrary files for
certificates that are nearing expiration. It's written in Java and it
currently works with PEM-encoded DER files (aka OpenSSL files) and
PKCS12 keystores. I'm sure it would also work with the other flavors
of Java key store, but I haven't (yet) tried them.

What I have noticed is that:

  KeyStore ks = KeyStore.getInstance("JKS");
  ks.load(pkcs12InputStream, null);

...seems to have no problem whatsoever with the fact that the
"keystore type" is JKS but the file being loaded is PKCS12. That makes
sense to me, since the in-memory keystore doesn't really have a
"type": only the on-disk representation of the keystore has a "type", et
c.

All of the information I can find online seems to indicate that the
(in-memory) KeyStore "type" must match what you are loading, or you'll
get an exception. But I'm finding that the in-memory type doesn't
matter, and the load works as long as the file is legit.

But the in-memory type doesn't change when the file is loaded. Hmm.

So two off-topic questions:

1. Can I rely on the "type doesn't matter" behavior I'm seeing, or do
I have to loop-over all the supported keystore types, attempting to
(re)load the file each time looking for the right type -- just to be saf
e?

2. Is there a way to determine the type of file that WAS loaded into a
KeyStore? It seems that there is a magic header I can use if I want to
look at the raw bytes to detect the Java keystore formats (0-feedfeed,
0xcececece), but I think that's not exactly true for PKCS12 and maybe
some other supported formats. I'd rather not look at the bytes myself
unless it's absolutely necessary.

Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7IPbgACgkQHPApP6U8
pFiyxw//RRNFh6nhgpSfqSzxsPDks3DqOfOnBLkI+0aRNtWkawlg+hM/nP96r9v5
IgL4qHZCz5fc2a8a5g+BsE4kM5yInSuvgAU+UtJhePNwE+2soSEYkAmjOEDOFT1J
3XCcKYAwS2c1laO3TeYXQdzgFJqwyu7my97eY3pjYB8WpfsRebYu693GOzGE8jII
HxWTiyavtzvu7dzRCx2czEyGlUVjkC7vClhC6njcEsG5lZXGW2rMupnSbYsGA9WZ
6UowafaEIAFWwLmBVauBP+4ZrUkJCoG2+Od8B55XpHdLvpKIeik6yqzshamb5z+5
rs2QTrm5Ta5UnP5l9Kf/99zuwmc4JQYLG2IeNwbw4SGVkn1MHOAArkkXJCBhWPKg
tqhYRIFkj6ZAqbVMIQe8j7dGzfr4+ZJa+yHCp4UT1N4GSQu2HGJ9i/olfXcCU3YV
j/YvO/qUcPudIwTIMbF0fKCSd4dUt4rt1zMBNUvJKW404EsQCt1HJuo3nluhBGTt
DIB4/qkhQKkHlQDq9FNzGHoQ5sX4qJcBAh6EMnjxFYyv3sPpbHFkGHbqylW9Wvwe
pVY9HcrPzocS0y/FCDQThiG5S2BMA+5eC7Fgmz2Hlqzl8dokoIDuOrJ4P50spsmc
HAhNaHQicGKq14fCT3kCh0lBqFMwDnat/JzJ1d5arZDN7PALCcg=
=RuBR
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to