To replicate:

1. Set up a Java TLSv1.2 server and run using -Djavax.net.debug=ssl,handshake
2. Connect using openssl s_client -curves prime192v1 -connect <host>:<port>

The OpenSSL installation needs to support additional curves (I couldn't replicate the issue with the RHEL 6.8 one as it only supports the same three curves that our OpenJDK build does). The above -curves command to OpenSSL restricts it to passing just:

Extension elliptic_curves, curve names: {1.2.840.10045.3.1.1}

to the server rather than a full list of all curves.

The issue is that OpenJDK's SunEC provider with NSS doesn't support prime192v1, yet the unpatched Java code believes it does.

On unpatched, the connection fails when it thinks it can use its first preference cipher, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, but the actual
key generation throws an exception:

%% Initialized:  [Session-1, SSL_NULL_WITH_NULL_NULL]
matching alias: rsakey
main, handling exception: java.lang.RuntimeException: Could not generate DH keypair
%% Invalidated:  [Session-1, SSL_NULL_WITH_NULL_NULL]
main, SEND TLSv1.2 ALERT:  fatal, description = internal_error

On patched, it realises they share no supported curves, and so downgrades to a non-ECC connection which works:

%% Initialized:  [Session-1, SSL_NULL_WITH_NULL_NULL]
matching alias: rsakey
matching alias: usaduke
matching alias: dsakey
%% Negotiating:  [Session-1, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384]

I've created a quick reproducer that requires just python and few pure-python libraries that tests that:

https://github.com/tomato42/tlsfuzzer/blob/ecdhe-curves/scripts/test-unsupported-cuve-fallback.py

Usage: https://github.com/tomato42/tlsfuzzer/tree/ecdhe-curves#usage

Please contact me if you plan to use it in RHEL QA.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2016:1409