Bug 44223 - Tomcat ignores the "javax.net.ssl.trustStoreType" system property
Tomcat ignores the "javax.net.ssl.trustStoreType" system property
Status: RESOLVED FIXED
Product: Tomcat 6
Classification: Unclassified
Component: Connectors
6.0.14
Other other
: P2 normal (vote)
: default
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2008-01-14 04:24 UTC by Ivan Todoroski
Modified: 2008-01-28 13:34 UTC (History)
0 users



Attachments
simple fix (873 bytes, patch)
2008-01-14 04:26 UTC, Ivan Todoroski
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan Todoroski 2008-01-14 04:24:16 UTC
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.
Comment 1 Ivan Todoroski 2008-01-14 04:26:15 UTC
Created attachment 21383 [details]
simple fix
Comment 2 Mark Thomas 2008-01-14 13:13:06 UTC
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.
Comment 3 Ivan Todoroski 2008-01-17 04:12:09 UTC
(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.
Comment 4 Mark Thomas 2008-01-18 13:00:47 UTC
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.
Comment 5 Mark Thomas 2008-01-28 13:34:43 UTC
This has been fixed in svn and will be included in 6.0.16 onwards.