Bug 48532 - try to read truststore even when clientauth is false
Summary: try to read truststore even when clientauth is false
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Webapps:Documentation (show other bugs)
Version: 5.5.28
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2010-01-12 22:26 UTC by Kent Tong
Modified: 2010-01-13 03:29 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Kent Tong 2010-01-12 22:26:00 UTC
When people try to set up SSL with Tomcat, most of them don't need client authentication and thus won't set the truststoreFile, truststorePass and etc. However, Tomcat (or rather, JSSESocketFactory) will always try to load the trust store. Somehow it got a valid path but the password (by default set to that for the keystore) is incorrect and will throw an exception like below. This is very
confusing as people will keep checking the password of their keystore (and
don't know anything about trust store).

I'd recommend the following solutions (most preferred listed first):
1) don't load the trust store if client authentication is false.
2) if a trust store is not specified, use the keystore.
3) the SSL howto should emphasize that a trust store must be set up.

sample stack trace:

java.io.IOException: Keystore was tampered with, or password was incorrect
        at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:771)
        at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:3
        at java.security.KeyStore.load(KeyStore.java:1185)
        at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocket
        at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getTrustStore(JSSES
        at org.apache.tomcat.util.net.jsse.JSSE14SocketFactory.getTrustManagers(
        at org.apache.tomcat.util.net.jsse.JSSE15SocketFactory.getTrustManagers(
Comment 1 Mark Thomas 2010-01-13 03:29:14 UTC
Changing version since the stack trace is from Tomcat 5.

I suspect you were caught out by the undocumented feature whereby Tomcat uses a number of system properties to determine defaults for the trust store. I have updated the SSL config docs to make this clearer.