You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "James H. H. Lampert" <ja...@touchtonecorp.com> on 2020/09/08 19:13:27 UTC
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL debug?
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
On 9/8/20 1:12 PM, John.E.Gregg@wellsfargo.com.INVALID wrote:
> 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.
I don't blame you. It's been close to a month since I last attempted to
do something about this.
The problem is that when the webapp tries to call the Google
https://maps.googleapis.com/maps/api/geocode
web service, it gets:
> Unable to find acceptable protocols. isFallback=false,
> modes=[ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
> TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_2, TLS_1_1,
> TLS_1_0], supportsTlsExtensions=true),
> ConnectionSpec(cipherSuites=[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
> TLS_RSA_WITH_3DES_EDE_CBC_SHA], tlsVersions=[TLS_1_0],
> supportsTlsExtensions=true), ConnectionSpec()], supported
> protocols=[TLSv1]
In the past, removing DESede from the list of disabled algorithms solved
the problem, but it appears that in the latest IBM Java 8 JVMs, DESede
was not only disabled, but *removed* from the JVM.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: SSL debug?
Posted by Jo...@wellsfargo.com.INVALID.
James,
> -----Original Message-----
> From: James H. H. Lampert <ja...@touchtonecorp.com>
> Sent: Tuesday, September 08, 2020 2:13 PM
> To: Tomcat Users List <us...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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.