James, > -----Original Message----- > From: James H. H. Lampert <jam...@touchtonecorp.com> > Sent: Tuesday, September 08, 2020 2:13 PM > To: Tomcat Users List <users@tomcat.apache.org> > Subject: Re: SSL debug? > > I'm finally back on this problem. > > >> We are once again having SSL difficulties with our webapp connecting > >> with an outside web service: the java.security override that had > >> solved the problem in the past (specifically, removing "DESede" from > >> the "jdk.tls.disabledAlgorithms" in an override file) is now failing > >> with certain Java 8 JVMs on AS/400s. > > More specifically, the call is to > https://maps.googleapis.com/maps/api/geocode > > Last month, I got a suggestion (on the Midrange Java List, but endorsed > when I asked about it here) of adding "-Djavax.net.debug=ssl:handshake" > to catalina.sh. > > Today, I finally tried it. It took several tries before I got anything at > all, but > when I did, I got 678k of information. Any suggestions on where my > proverbial needle would be in that haystack, and what it would look like? > > Also today, I tried the "sledgehammer" approach of editing the JVM's own > java.security instead of merely overriding it. No difference. > > -- > JHHL > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org
I don't remember the precise problem, but verbose SSL will tell you what trust store and key store you're using, among other things. You'll see something like this: keyStore is: /path/to/keystore ... trustStore is: /path/to/truststore ... Are those the right files? After the trustStore path, you should then see a list of all the CAs in the trust store. Ideally, you'd do this on a quiet system. As you've seen, it produces a ton of output and there is no way to distinguish messages from one thread vs another.
