The application is based on Java and Tomcat server. Which type of keystore is better ? does JKS or PCKS12 ? I understand JDK keytool by default creates JSK type then for which uses-cases one should go for PKCS12 type ?

I tried creating PKCS12 keystore but unable to generate CSR using keytool -certq. The command fails with an error - Invalid keystore format.

  • In any Java since 5 (IIRC) try keytool -certreq -keystore $file -storetype pkcs12. For recent Suncle Java (8u60 or up) it should work even without storetype, unless you or someone has diddled keystore.type.compat in java.security Commented Sep 9, 2017 at 1:07

2 Answers 2


My understanding is that you need to use a Java KeyStore (JKS) object for in-memory handling of certs and keys anyway. The fact that keytool does not know what to do with a P12 is evidence of this. The question is about how you store it on disk.

Both JKS and P12 files use strong encryption. P12 is needed if you want to share keys and certs between a java-based application (ie Tomcat) and a C or C++ application (maybe using openssl under the hood). If your stack is entirely java, then there's no reason to have each process disassemble the JKS into P12 files, and then have each process re-assemble P12s back into a JKS.

Think of P12 as the "Export to PDF" of the certificate world.

  • Java/JCE supports multiple key+chain pairs in one PKCS12 with 'friendly names' implementing the JCA aliases (and j8 further supports lone certificates not matching a key) although openssl commandline will create only one key+chain per file (libcrypto can do more if you write your own program). OTOH the simple I/O routines, used IME by many OpenSSL apps, support only 'legacy' or PKCS8 PEM files, not PKCS12. (And OpenSSL's 'legacy' key files use poor PBE!) Although I concur PKCS12 is the most common/portable format we have. Commented Sep 9, 2017 at 1:06
  • Okay then there is no security recommendations of using PKCS over JKS right ? does FIPS 140 demands PKCS ? Commented Sep 12, 2017 at 9:29
  • @user1493834 Crypto-wise, I believe they are equivalent. Both are well thought-out implementations. For FIPS 140, I have no idea. I mean, FIPS-140 validates the crypto engine (ie running software), not data formats, so you'd need to figure out which crypto engine is being used under the hood (probably the JCE), then look up the FIPS validation documents for it: is it even validated? If so, the documents should tell you how you need to use it in order to be using it in a FIPS mode. Commented Sep 12, 2017 at 12:51
  • @user1493834 you should definitely prefer PKCS12, see iammyr's answer. Commented May 22, 2019 at 22:40

According to https://neilmadden.wordpress.com/2017/11/17/java-keystores-the-gory-details/ it seems that PKCS#12 is the only "decent" choice between the different keystores. Ideally you would also specify PBEWithHmacSHA512AndAES_256 as custom PasswordProtection, as it is allowed in Java8.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .