[Bug 55770] New: Allow the crlFile to be reloaded

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=55770

            Bug ID: 55770
           Summary: Allow the crlFile to be reloaded
           Product: Tomcat 8
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Connectors
          Assignee: dev@tomcat.apache.org
          Reporter: dmikusa@gopivotal.com

There have been a few recent requests on the users list for the ability to
reload the crlFile.

  http://tomcat.markmail.org/message/fa7rqbjmqadzxxok
  http://tomcat.markmail.org/message/kid5zlnlznsflhkz

Would it be possible to reload the file if it changes?  If that's not possible,
how about exposing the ability to reload it through JMX?

Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 55770] Allow the crlFile to be reloaded

[bu...@apache.org]

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 55770] Allow the crlFile to be reloaded

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=55770

--- Comment #1 from Christopher Schultz <ch...@christopherschultz.net> ---
For the JSSE connector, it appears that changing the TrustManager itself is
non-trivial: it would require that the SSLServerSocketFactory be re-built from
scratch, the connector would have to detach from the port and re-bind to it.
That's obviously not a good solution.

However, the TrustManager itself could be rigged to re-load the CRL at an
interval. I'd have to look to see how the stock TrustManagers work... if they
do any kind of trust-caching things might not go well.

Assuming there's no problem with a TrustManager that changes behavior over
time, this should be doable... for JSSE anyway.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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