Set up a SSL Connector with a keystore in JKS format: <Connector ... SSLEnabled="true" keystoreFile="tomcat.keystore" keystoreType="JKS"> Let's say you need a custom truststore (e.g. for authenticating self-signed client certificates), and that this truststore is also needed by some of your webapps, not only Tomcat. The natural thing to do then is to configure this truststore globally for the whole JVM, not in server.xml. Let's also assume this truststore is in a different format (e.g. PKCS#12). So before starting Tomcat, you do this: export JAVA_OPTS="-Djavax.net.ssl.trustStore=trusted.keystore - Djavax.net.ssl.trustStoreType=PKCS12" Well, it doesn't work. If you look at tomcat/logs/catalina.out, you will see a keystore-related exception. Upon further debugging, you will discover the problem is that Tomcat is trying to open the truststore as if it were in JKS format, even though it is clearly specified as type PKCS12 in JAVA_OPTS above.
Created attachment 21383 [details] simple fix
Tomcat ignores any of the SSL configuration system properties. I was going to say it has always been this way, I didn't know why and if you provided a patch that addressed all of them it would be considered. However, my brain is now in gear and the problem seems obvious. When using system properties for configuration then everything is fine until two components require conflicting settings. In a container environment this pretty much a given. We had a similar issue with logging which is why Remy wrote JULI. Therefore, I am marking this as a WONTFIX on the grounds I see it causing more problems than it solves.
(In reply to comment #2) > Tomcat ignores any of the SSL configuration system properties. But this statement is not true. Tomcat already consults the "javax.net.ssl.trustStore" and "javax.net.ssl.trustStorePassword" properties, only it was ignoring the third one, "javax.net.ssl.trustStoreType". I am not asking for a new feature here, this bug is about the inconsistent implementation of an existing feature. Look at the JSSESocketFactory.getTrustStore() method to see what's going on. > I was going to say it has always been this way, I didn't know why and if you > provided a patch that addressed all of them it would be considered. Well this patch completes the addressing of all of them. Only 2 out of 3 trust store related properties are being taken into account at the moment, and this patch adds support for the 3rd one. Either this inconsistency should be fixed, or else remove support for ALL trust store properties. The current situation is inconsistent and leads to maddening configuration issues (i.e. any reasonable person would assume that since 2 trust store properties appear supported the third one would be also, and then scratch their head when a non-descriptive JSSE exception hits them). > However, my brain is now in gear and the problem seems obvious. When using > system properties for configuration then everything is fine until two components > require conflicting settings. In a container environment this pretty much a > given. We had a similar issue with logging which is why Remy wrote JULI. > > Therefore, I am marking this as a WONTFIX on the grounds I see it causing more > problems than it solves. While I agree with your reasoning about container environments, I disagree with the WONTFIX assessment. Currently you have partial support for an arbitrary subset of trust store properties, which is the worst of both worlds. Either support all of them or none of them.
Fair point. I didn't realise we were using the others. Still don't like it but that is an issue for another time. Patch applied to trunk and proposed for 6.0.x. Many thanks.
This has been fixed in svn and will be included in 6.0.16 onwards.