tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 44223] - Tomcat ignores the "javax.net.ssl.trustStoreType" system property
Date Thu, 17 Jan 2008 12:12:20 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44223>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44223


grnch@gmx.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |




------- Additional Comments From grnch@gmx.net  2008-01-17 04:12 -------
(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.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message