You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Edward Quick <Ed...@iggroup.com> on 2011/10/11 15:21:20 UTC
ssl handshake problem
Hi,
I have an ssl handshake issue with an application running on tomcat that talks to an ssl site. This site renewed their ssl certificate recently, however it was signed with the G5 and G3 intermediate verisign CA certificates which are imported into the java truststore that my tomcat uses.
If I run a short java program from the command line to connect to the site using tomcat's truststore it works fine. I'm just wondering if tomcat needs a restart to pick the new certificate up from this site? Or is there an mbean operation I can invoke to clear this out? Obviously I'm speculating, but I'm a bit stuck on this and as it's running a live service, it's not easy to restart.
Thanks for any help.
Ed.
________________________________
The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Group Holdings plc is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Cannon Bridge House, 25 Dowgate Hill, London EC4R 2YA. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
RE: ssl handshake problem
Posted by Edward Quick <Ed...@iggroup.com>.
Sorry I meant it was a java issue (typo!)
-----Original Message-----
From: Edward Quick
Sent: 17 October 2011 09:17
To: Tomcat Users List
Subject: RE: ssl handshake problem
Hi Andre, thanks for your reply.
I tested this a bit more and did a write up of the problem for anyone who's interested http://www.linuxcrusaders.org/blog/node/45
Obviously it wasn't a java issue not tomcat-related though.
Regards,
Ed.
-----Original Message-----
From: André Warnier [mailto:aw@ice-sa.com]
Sent: 12 October 2011 16:41
To: Tomcat Users List
Subject: Re: ssl handshake problem
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Group Holdings plc is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Cannon Bridge House, 25 Dowgate Hill, London EC4R 2YA. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
RE: ssl handshake problem
Posted by Edward Quick <Ed...@iggroup.com>.
Hi Andre, thanks for your reply.
I tested this a bit more and did a write up of the problem for anyone who's interested http://www.linuxcrusaders.org/blog/node/45
Obviously it wasn't a java issue not tomcat-related though.
Regards,
Ed.
-----Original Message-----
From: André Warnier [mailto:aw@ice-sa.com]
Sent: 12 October 2011 16:41
To: Tomcat Users List
Subject: Re: ssl handshake problem
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Group Holdings plc is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Cannon Bridge House, 25 Dowgate Hill, London EC4R 2YA. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
Re: ssl handshake problem
Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: ssl handshake problem
Posted by Edward Quick <Ed...@iggroup.com>.
Found out the reason for the ssl handshake error. The certificate chain was in the wrong order (being server certificate, Root CA, Intermediate, instead of server certificate, Intermediate, Root CA).
-----Original Message-----
From: Edward Quick [mailto:Edward.Quick@iggroup.com]
Sent: 12 October 2011 08:12
To: Tomcat Users List
Subject: RE: ssl handshake problem
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?
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: 11 October 2011 16:30
To: Tomcat Users List
Subject: Re: ssl handshake problem
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Edward,
On 10/11/2011 9:21 AM, Edward Quick wrote:
> I have an ssl handshake issue with an application running on
> tomcat that talks to an ssl site. This site renewed their ssl
> certificate recently, however it was signed with the G5 and G3
> intermediate verisign CA certificates which are imported into the
> java truststore that my tomcat uses.
>
> If I run a short java program from the command line to connect to
> the site using tomcat's truststore it works fine. I'm just
> wondering if tomcat needs a restart to pick the new certificate up
> from this site? Or is there an mbean operation I can invoke to
> clear this out? Obviously I'm speculating, but I'm a bit stuck on
> this and as it's running a live service, it's not easy to restart.
So, if the service is restarted, you're confident that the handshake
will work? If that's the case, I believe a Tomcat restart is your only
option at this point.
Another option would be to manage your own trust store for your
outgoing communications instead of relying on Tomcat's trust store. Of
course, that requires you to modify your webapp which might not be
terribly convenient.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6UYPUACgkQ9CaO5/Lv0PAGsgCfc9ORPVz7v9GlwhQZFRhVJZRr
jhoAn1r/Sl+KR57wfi8UwRTjkOMD5TTQ
=9b/8
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Group Holdings plc is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Cannon Bridge House, 25 Dowgate Hill, London EC4R 2YA. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
RE: ssl handshake problem
Posted by Edward Quick <Ed...@iggroup.com>.
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?
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: 11 October 2011 16:30
To: Tomcat Users List
Subject: Re: ssl handshake problem
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Edward,
On 10/11/2011 9:21 AM, Edward Quick wrote:
> I have an ssl handshake issue with an application running on
> tomcat that talks to an ssl site. This site renewed their ssl
> certificate recently, however it was signed with the G5 and G3
> intermediate verisign CA certificates which are imported into the
> java truststore that my tomcat uses.
>
> If I run a short java program from the command line to connect to
> the site using tomcat's truststore it works fine. I'm just
> wondering if tomcat needs a restart to pick the new certificate up
> from this site? Or is there an mbean operation I can invoke to
> clear this out? Obviously I'm speculating, but I'm a bit stuck on
> this and as it's running a live service, it's not easy to restart.
So, if the service is restarted, you're confident that the handshake
will work? If that's the case, I believe a Tomcat restart is your only
option at this point.
Another option would be to manage your own trust store for your
outgoing communications instead of relying on Tomcat's trust store. Of
course, that requires you to modify your webapp which might not be
terribly convenient.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6UYPUACgkQ9CaO5/Lv0PAGsgCfc9ORPVz7v9GlwhQZFRhVJZRr
jhoAn1r/Sl+KR57wfi8UwRTjkOMD5TTQ
=9b/8
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Group Holdings plc is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Cannon Bridge House, 25 Dowgate Hill, London EC4R 2YA. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
Re: ssl handshake problem
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Edward,
On 10/11/2011 9:21 AM, Edward Quick wrote:
> I have an ssl handshake issue with an application running on
> tomcat that talks to an ssl site. This site renewed their ssl
> certificate recently, however it was signed with the G5 and G3
> intermediate verisign CA certificates which are imported into the
> java truststore that my tomcat uses.
>
> If I run a short java program from the command line to connect to
> the site using tomcat's truststore it works fine. I'm just
> wondering if tomcat needs a restart to pick the new certificate up
> from this site? Or is there an mbean operation I can invoke to
> clear this out? Obviously I'm speculating, but I'm a bit stuck on
> this and as it's running a live service, it's not easy to restart.
So, if the service is restarted, you're confident that the handshake
will work? If that's the case, I believe a Tomcat restart is your only
option at this point.
Another option would be to manage your own trust store for your
outgoing communications instead of relying on Tomcat's trust store. Of
course, that requires you to modify your webapp which might not be
terribly convenient.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6UYPUACgkQ9CaO5/Lv0PAGsgCfc9ORPVz7v9GlwhQZFRhVJZRr
jhoAn1r/Sl+KR57wfi8UwRTjkOMD5TTQ
=9b/8
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org