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.qu...@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:ch...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@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.
