tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.
Date Wed, 04 Oct 2017 20:41:46 GMT
Hash: SHA256


On 10/4/17 3:44 PM, James H. H. Lampert wrote:
> On 10/4/17, 12:26 PM, Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> James,
> . . .
>> Okay so you are in no way interfering with the defaults. That
>> means you'll get (depending upon your exact versions of various
>> things) a Tomcat which supports TLSv1 or later, and most of the
>> cipher suites that are shown as "default" above.
>> Your choice of TLS certificate may affect some of the things that
>> you can do, but I see that you've got an RSA certificate from the
>> output from SSLLabs, so you shouldn't have any problems with a
>> DSS certificate or anything like that. (Use of DSS certs these
>> days is fairly rare).
> . . .
>> Strange. I would have expected Tomcat to enable more cipher
>> suites with a default configuration given the SSLInfo output
>> above.
>> Are you sure you are using the same Java version with Tomcat as
>> you did to run those commands above?
> Dear Mr. Schultz:

"Chris" is fine. We're all friends, here.

> It sure looks like the same Java version. Here is what the manager
> returns:
>> Apache Tomcat/8.5.14 (Debian) 1.7.0_151-b01 Oracle Corporation 
>> Linux     3.16.0-4-amd64     amd64
> It would definitely be helpful if the OS/400 names of the cipher
> suites more precisely matched the Java names. To recap, the QSSLCSL
> system value on the AS/400 shows (using the OS/400 naming
> conventions)
>> *RSA_AES_128_CBC_SHA *RSA_RC4_128_SHA *RSA_RC4_128_MD5 

If you know how to "read" cipher suite descriptions, the differences
don't matter much. They are all made-up of the following components:

1. protocol (not shown in OpenSSL-style names, like those above)
2. authentication algorithm (usually RSA, ECDH, or ECDHE)
3. bulk (symmetric) cipher algorithm (e.g. RC4, AES-128, 3DES, Camellia)
   This includes the "block cipher mode e.g. CBC, GCM, etc.)
4. signature algorithm (e.g. MD5, SHA, etc.)

The differences between the cipher suite names in different tools
comes down to how expressive they are. For example, Java says "SSL_"
or "TLS_" before every cipher, but that's largely useless. Some names
in different dialects show different levels of detail about the
underlying algorithms, or are more readable.

Take this one for example. Java (and SSLLabs) calls it
"TLS_RSA_WITH_AES_128_CBC_SHA" but the same algorithm is called
"RSA_AES_128_CBC_SHA" by OpenSSL and similar tools. It's all still in
there.. it's just that OpenSSL doesn't bother with the "TLS_" prefix
and the "_WITH_" embedded in the middle.

When it all comes down to it, the TLS (nee SSL) spec defines certain
cipher suites by "cipher id" which is a numeric, explicitly-defined
set of crypto primitives combined into a "cipher suite", which will be
negotiated by the client and server when they perform their initial

You can read all the gory details here[1]. For example, the
aforementioned RSA_AES_128_CBC_SHA cipher suite is cipher 0x00002F. It
doesn't matter what the tool calls it; cipher 0x00002f always has
those criteria. Of course, they aren't very readable.

That document is a bit out of date, but it does show you how things
were back in 2009, and makes you wonder why it took so damned long for
The World to adopt TLSv1.2.

- -chris

Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message