https://issues.apache.org/bugzilla/show_bug.cgi?id=55770
--- Comment #2 from Christopher Schultz <ch...@christopherschultz.net> --- It turns out this is something of a mess. During initialization, the connector (really o.a.t.util.net.jsse.JSSESocketFactory) sets-up a set of TrustManager objects in an array, which are passed-into SSLContext.init. After that, who knows. We can wrap a TrustManager in another object, but TrustManager itself doesn't have any methods. Instead, there is a subinterface called X509TrustManager that does have actual methods. Unfortunately, the standard way of getting TrustManagers that work off of a trust store and a CRL ultimately returns an array of ... TrustManagers. So, you either have to assume that the only useful implementation of a TrustManager is an X509TrustManager (which isn't a bad assumption, really, but could end up biting us in the future) or that the only thing that will come out of that standard setup procedure (an array of TrustManagers) will have exactly one TrustManager in it -- and we can replace one with the other in the existing array being used by the SSLContext. This will all fall apart if the SSLContext does something sensible like making a defensive copy of the array it gets from the calling code. I think perhaps the only way to do this would be to make a few assumptions and hope for the best. That seems to be what Hadoop does (see below). References: http://jcalcote.wordpress.com/2010/06/22/managing-a-dynamic-java-trust-store/ http://svn.apache.org/repos/asf/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/ssl/ReloadingX509TrustManager.java -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
