JDK-8194749 : password handling with keytool -cacerts
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2018-01-08
  • Updated: 2019-05-31
  • Resolved: 2019-05-31
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
keytool has a -cacerts flag to operate on the internal cacerts file (thanks!).
BUT:
 keytool still wants a storepass, even though it obviously knows how to read from the cacerts file, and there is little security here since all cacerts files have the same well-known storepass.  The keytool docs say """When retrieving information from the keystore, the password is optional. If no password is specified, then the integrity of the retrieved information can't be verified and a warning is displayed."""

BUT: 
 $ keytool -list -cacerts -storepass bogus
keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect

It is possible to get the data, but you have to get the prompt, then ENTER (null password) to get the desired output.

 $ keytool -list -cacerts
Enter keystore password:  

*****************  WARNING WARNING WARNING  *****************
* The integrity of the information stored in your keystore  *
* has NOT been verified!  In order to verify its integrity, *
* you must provide your keystore password.                  *
*****************  WARNING WARNING WARNING  *****************

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 80 entries
...

All of this seems to make no sense.  With keytool -cacerts, java should just access the cacerts using whatever means it normally uses (I'm not sure how ... does it hard-code the well-known password?)
Comments
With cacerts migrated into password-less pkcs12, these problems will go away.
31-05-2019

These are the most common actions on cacerts: 1. Adding (first or more) entries "keytool -importcert". 2. Listing one or all entries "keytool -list" or "keytoo -exportcert". 3. Converting keystore "keystore -importkeystore", to and from. 4. Removing one entry "keystore -delete". Since we are thinking of password-less pkcs12 keystores, we should at least make keytool behave friendly in these cases.
26-07-2018

This looks annoying but a user can always change the storepass of cacerts. The best way I can think of now is to hard-code a null password, but as you know, this will not work for pkcs12. Let's wait until the pkcs12 password issue (linux-x64/bin/java A) is resolved.
09-01-2018