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

[Bernd]

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.

Btw: the initial issue „which certificate“ would suggest the byte position beeing more important than the file name - especially if there can only be so many ways to specify one. Maybe instead of throwing the details just error log the path?

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

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