help clear up my misconception about s_client and protcols vs ciphersuites

[reichert@xxxxxxxxxxx (Brian Reichert)]

I'm using openssl s_client 1.0.1e-fips to test a Java-based webapp.
The webapp is showing errors that are cleared up when I update the
OpenJDK package on the server:

  javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate
  DH keypair

I'm trying to cobble some simple testing tools, using s_client, and
have found behavior that I can't explain.  I'm hoping someone can
provide a clue as to what I'm doing wrong. :)

This fails, and generates the Java exception on the server:

  # openssl s_client -connect localhost:8100 -cipher DEFAULT < /dev/null ; echo $?
  CONNECTED(00000003)
  140593476523848:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:744:
  ---
  no peer certificate available
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 7 bytes and written 249 bytes
  ---
  New, (NONE), Cipher is (NONE)
  Secure Renegotiation IS NOT supported
  Compression: NONE
  Expansion: NONE
  ---
  1

This succeeds:

  # openssl s_client -connect localhost:8100 -cipher ALL < /dev/null ; echo $?
  CONNECTED(00000003)
  [trimming certificate info]
  ---
  No client certificate CA names sent
  Server Temp Key: DH, 768 bits
  ---
  SSL handshake has read 1279 bytes and written 430 bytes
  ---
  New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA256
  Server public key is 1024 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  SSL-Session:
      Protocol  : TLSv1.2
      Cipher    : DHE-RSA-AES256-SHA256
      Session-ID:
  54822C7267D791574E057DCFB0AC9DF10D675F6C1329BC5DCE3939E82CFD1803
      Session-ID-ctx:
      Master-Key:
  410C247EFB00532F4EC685CAC1E5D9235697E2ACAB0522BD1B0CFCB997514A50A18033D6A2D7605452344E19A34C7987
      Key-Arg   : None
      Krb5 Principal: None
      PSK identity: None
      PSK identity hint: None
      Start Time: 1417817202
      Timeout   : 300 (sec)
      Verify return code: 10 (certificate has expired)
  ---
  DONE
  0

That shows me, if I read this correctly, that 

- I've established a TLSv1.2 session
- using DHE-RSA-AES256-SHA256
- even though this is in the DEFAULT ciphersuite, ALL allows something
  useful to occur

But, if I try to force s_client to expressly use TLSv1.2, the
original error shows up again:

  # openssl s_client -connect localhost:8100 -cipher ALL -tls1_2 < /dev/null ; echo $?
  [identical output as my first invocation]

Or even expressly disabling all other protocols:

  # openssl s_client -connect localhost:8100 -cipher ALL -no_ssl2 -no_ssl3 -no_tls1 -no_tls1_1 -tls1_2 < /dev/null ; echo $?

I guess I'm misusing this tool somehow, and would appreciate a clue...

-- 
Brian Reichert				<reichert at numachi.com>
BSD admin/developer at large