SSL debug?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

SSL debug?

James H. H. Lampert
Question:

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.

Somebody on the Midrange Java List suggested using

> -Djavax.net.debug=ssl:handshake

in catalina.sh, to gather more information on the problem.

Would that actually help with our present situation? Or would it only
cover problems with users connecting to Tomcat from their browsers?

--
JHHL

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SSL debug?

markt
On 12/08/2020 16:29, James H. H. Lampert wrote:

> Question:
>
> 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.
>
> Somebody on the Midrange Java List suggested using
>
>> -Djavax.net.debug=ssl:handshake
>
> in catalina.sh, to gather more information on the problem.
>
> Would that actually help with our present situation? Or would it only
> cover problems with users connecting to Tomcat from their browsers?

That should show TLS handshakes from both user agent to Tomcat and
application to external service.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: SSL debug?

James H. H. Lampert
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: SSL debug?

John.E.Gregg-2
James,

> -----Original Message-----
> From: James H. H. Lampert <[hidden email]>
> Sent: Tuesday, September 08, 2020 2:13 PM
> To: Tomcat Users List <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]

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.



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SSL debug?

James H. H. Lampert
On 9/8/20 1:12 PM, [hidden email] 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: [hidden email]
For additional commands, e-mail: [hidden email]