Edward Quick wrote:
Thanks for your reply Chris. No I'm not confident a restart would fix it.
Having said that I haven't seen the ssl handshake problem since yesterday
(which might be because the app hasn't tried the address yet) so waiting to see
if it happens again. Unfortunately I don't have a way to invoke it.
All my question was really is whether tomcat or java somehow caches an https
site's old ssl certificate for a while and checks its truststore against this
instead of the new one?
Maybe something to add : as I understand your original description, this is about a webapp
(running "inside" of Tomcat) which establishes its own SSL connection to some other server.
In such a case, as far as I know Tomcat is not involved at all. It doesn't even know that
the webapp is doing that, and has no reason to be caching anything.
This being said, since both Tomcat and the webapp "run inside" the same JVM, there may be
things cached /by the JVM/.
My knowledge of these things is insufficient to know if such things cached by the JVM
could be shared between Tomcat and the webapp.
Intuitively however, I would tend to think that whatever in-memory structure/object is
used by Tomcat for its own SSL Connector(s), is probably distinct from the in-memory
structure/object used by this webapp to store information related to its own independent
connections.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
