RFR: JDK-8311892: TrustManagerFactory loading an invalid keystore yield vague exception

[Sean Mullan]

On Tue, 11 Jul 2023 18:09:26 GMT, Craig Andrews <duke at openjdk.org> wrote:

> When loading the default JVM trust store, if the JVM trust store contains an invalid certificate, the exception contains insufficient information to determine which certificate is invalid, making it very difficult to fix the problem.
> 
> To reproduce the issue:
> 1. Modify the default JVM trust store to contain invalid information. A very easy way to do this on openjdk / red hat systems is to edit /etc/pki/ca-trust/extracted/java/cacerts and add garbage text to the file.
> 2. Run this code:
> 
> TrustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
> // initializing the trust store with a null KeyStore will load the default JVM trust store
> tmf.init((KeyStore) null);
> 
> 
> This stack trace results:
> 
> Caused by: java.security.KeyStoreException: problem accessing trust store
> 	at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:73)
> 	at java.base/javax.net.ssl.TrustManagerFactory.init(TrustManagerFactory.java:282)
> 	... 81 common frames omitted
> Caused by: java.io.IOException: toDerInputStream rejects tag type 97
> 	at java.base/sun.security.util.DerValue.toDerInputStream(DerValue.java:1155)
> 	at java.base/sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:2013)
> 	at java.base/sun.security.util.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:221)
> 	at java.base/java.security.KeyStore.load(KeyStore.java:1473)
> 	at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.loadKeyStore(TrustStoreManager.java:390)
> 	at java.base/sun.security.ssl.TrustStoreManager$TrustAnchorManager.getTrustedCerts(TrustStoreManager.java:336)
> 	at java.base/sun.security.ssl.TrustStoreManager.getTrustedCerts(TrustStoreManager.java:57)
> 	at java.base/sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:49)
> 	... 83 common frames omitted
> 
> 
> Throwing an exception with a more detailed error message facilitates debugging and ultimately fixing such problems.

Making this change would potentially reveal sensitive information about the file system (i.e. the pathname of the keystore) in an Exception message. This would go against the recommendations in [guideline 2.1 of the Java Secure Coding Guidelines](https://www.oracle.com/java/technologies/javase/seccodeguide.html). Thus, I do not accept this change as proposed.

You can already obtain similar helpful information by enabling debugging by specifying `-Djavax.net.debug=ssl:trustmanager` on the command-line.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14834#issuecomment-1636230292