Keystore Type: Which One to Use

Keystore type: which one to use?

There are a few more types than what's listed in the standard name list you've linked to. You can find more in the cryptographic providers documentation. The most common are certainly JKS (the default) and PKCS12 (for PKCS#12 files, often with extension .p12 or sometimes .pfx).

JKS is the most common if you stay within the Java world. PKCS#12 isn't Java-specific, it's particularly convenient to use certificates (with private keys) backed up from a browser or coming from OpenSSL-based tools (keytool wasn't able to convert a keystore and import its private keys before Java 6, so you had to use other tools).

If you already have a PKCS#12 file, it's often easier to use the PKCS12 type directly. It's possible to convert formats, but it's rarely necessary if you can choose the keystore type directly.

In Java 7, PKCS12 was mainly useful as a keystore but less for a truststore (see the difference between a keystore and a truststore), because you couldn't store certificate entries without a private key. In contrast, JKS doesn't require each entry to be a private key entry, so you can have entries that contain only certificates, which is useful for trust stores, where you store the list of certificates you trust (but you don't have the private key for them).

This has changed in Java 8, so you can now have certificate-only entries in PKCS12 stores too. (More details about these changes and further plans can be found in JEP 229: Create PKCS12 Keystores by Default.)

There are a few other keystore types, perhaps less frequently used (depending on the context), those include:

• PKCS11, for PKCS#11 libraries, typically for accessing hardware cryptographic tokens, but the Sun provider implementation also supports NSS stores (from Mozilla) through this.
• BKS, using the BouncyCastle provider (commonly used for Android).
• Windows-MY/Windows-ROOT, if you want to access the Windows certificate store directly.
• KeychainStore, if you want to use the OSX keychain directly.

Android Keystore Type which one should I choose?

Android seems to be using bouncycastle provider. This is the default provider that, the api returns. To be sure which one is available as default on the device use KeyStore.getDefaultType().

In my case this returned 'BKS'. Also there seems to be an exception when there is a '.' character in the keystore file path.

when I stored the store to a folder with the name of my package (as recommended in the Android documentation), it resulted in an exception.

you may like to check this also.

Mule 3 TLS what is the recommended keystore type

Mule doesn't makes any recommendation. It just defines JKS as the default format for keystores if you don't specify one explicitly. Other than that it just uses what your Java implementation provides. You should instead investigate the advantages and disadvantages of each format for your specific Java version and use cases.

How do I specify the keystore type on the command line?

-Dname=value sets a system property; the settings in java.security are security properties not system properties, and cannot be directly set on command line. You can create a supplementary (or replacement) file and specify that with a sysprop -Djava.security.properties=name_of_file_containing_keystore_setting as long as you (or anyone else) did not change the default setting of security.overridePropertiesFile=true in java.security. Similar: How can I disable TLSv1 without change source code? .

Note that if you only need to change the type of the truststore and/or keystore used by JSSE for SSL/TLS/HTTPS/etc by default, those do use sysprops javax.net.ssl.{trust,key}StoreType (along with {trust,key}Store{,Password}).

Also you might want to be aware that Java9 up changes the as-installed default to PKCS12, which is both more secure and more portable/interoperable than JKS.

What is the difference between a PKCS12 keystore and a PKCS11 keystore?

PKCS#12 is a file format (often called .p12 or .pfx) where you can store a private key and certificates. It's used for converting/transporting keys and certificates, mainly. If you export a private key + certificate from your browser, it's likely going to be in that format.

PKCS#11 is an interface, usually used to talk to hardware cryptographic tokens (often smart-cards or USB-tokens, which effectively are smart-cards embedded in a reader). This interface has a number of operations to make use of the keys and certificates. Some tokens are able to sign using the private key they contain, without the key being able to leave the device.
The point of this interface is to treat what handles the keys and certificates as a separate entity, without having to do the cryptographic operations that PKCS#11 offer (more specifically, the ones related to the private key).

When you use PKCS#11 with NSS, you're effectively using NSS as a black-box wrapped behind the PKCS#11 layer (it's effectively a software provider for what a PKCS#11 hardware token would be). There is a slight difference in the way Java uses NSS via PKCS#11 in that it doesn't require a PKCS#11 shared library (compared to other PKCS#11 libraries), so as such, it's not PKCS#11 strictly speaking, although it's very similar.

In Java, you may be able to get an RSAPrivateKey instance from a PKCS#11 store, use it to sign and decipher, without ever being able to get anything from its modulus. The security provider handling it will do the signing/deciphering via the library (and thus via the token, if that library is supported by a hardware token).

Coming back to the KeyStore in Java, it's an API that can allow you to load and use keys and certificates from files (you get various files formats such as JKS, PKCS#12, PEM, depending on your security provider) or from other underlying APIs (such as PKCS#11, more or less merged with NSS in the Sun provider, or the KeychainStore if you're on OSX and want to use the KeyChain as a KeyStore).

---

Related Topics