A DESCRIPTION OF THE REQUEST :
When using the keytool command to manage the import of a CA signed certificate into a java keystore, if the -trustcacerts option is used, the keytool command ignores a previously defined jssecacerts file.

The X509TrustManager Interface identifies that cacerts and jssecacerts should be interchangeable, as described here:

http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#X509TrustManager

But this is not true for the keytool command line.

JUSTIFICATION :
This can create confusion (and additional work) for administrators attempting to validate issued certificates against trusted CA's during import. Confusing error messages are presented such as:

"keytool error: java.lang.Exception: Failed to establish chain from reply"

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The keytool -trustcacerts should check for jssecacerts in the $JAVA_HOME/jre/lib/security path, if its there use it. (basically follow whats laid out as order of precedence in the x509 TrustManager docs: http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#X509TrustManager )

 -J-Djavax.net.ssl.trustStore=/path/to/alternative-truststore should also be considered as well if used in conjunction with -trustcacerts flag.
ACTUAL -
Private CA certificates imported into the $JAVA_HOME/jre/lib/security/jssecacerts file are ignored

If Private CA certificates are imported into the $JAVA_HOME/jre/lib/security/cacerts file they are used as expected.

CUSTOMER SUBMITTED WORKAROUND :
The CA certificates must be imported into the java keytore that the certificate is being imported into first, OR the private certificates imported into the default $JAVA_HOME/jre/lib/security/cacerts file (considered bad practice to modify the default file).

Not using -trustcacerts is probably an option as well, but not optimal if CA validation is desired for imported certificates are desired.