MySQL Connector 8.0.20 Fails on IBM JDK 1.8: SSL Handshake Root Cause & Fixes

Phenomenon

Upgrading MySQL Connector/J from 8.0.18 to 8.0.20 in an IBM JDK 1.8 environment triggers a

javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)

. The same upgrade works on OpenJDK 1.8.

Analysis

1. Official documentation

MySQL supported protocols and cipher suites – MySQL Connector/J 8.0.x attempts TLS v1, TLS v1.1, TLS v1.2 and TLS v1.3. Starting with 8.0.19 the driver ships a TlsSettings.properties file that limits cipher suites to those whose names begin with TLS.

MySQL driver release notes – The TlsSettings.properties file is located at src/main/resources/com/mysql/cj/TlsSettings.properties in versions 8.0.19 and 8.0.20; version 8.0.18 does not contain this file.

IBM JSSE2 supported protocols and cipher suites – IBM JDK 1.8 supports SSL, TLS, TLSv1, TLSv1.1 and TLSv1.2. Most of its cipher suites are prefixed with SSL rather than TLS. IBM provides the system property com.ibm.jsse2.overrideDefaultCSName=true to make the naming compatible with Oracle/OpenJDK.

Reference: https://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/ciphersuites.html

2. Packet capture analysis

(1) IBM JDK 1.8 + mysql‑connector‑java‑8.0.20

Running the JDBC client with -verbose and -Djavax.net.debug=true shows attempts to use TLS 1.3, 1.2, 1.1 and 1.0, but no cipher suite is available for any of them.

javax.net.ssl|FINE|01|main|2021-03-30 11:47:33.493 UTC|Thread.java:1164|No available cipher suite for TLS13</code><code>javax.net.ssl|FINE|01|main|2021-03-30 11:47:33.493 UTC|Thread.java:1164|No available cipher suite for TLS12</code><code>javax.net.ssl|FINE|01|main|2021-03-30 11:47:33.493 UTC|Thread.java:1164|No available cipher suite for TLS11</code><code>javax.net.ssl|FINE|01|main|2021-03-30 11:47:33.494 UTC|Thread.java:1164|No available cipher suite for TLS10

The logs confirm that IBM JDK cannot find matching cipher suites for the requested TLS versions.

(2) IBM JDK 1.8 + mysql‑connector‑java‑8.0.20 + com.ibm.jsse2.overrideDefaultCSName=true

Setting the system property makes the connection succeed. Debug logs show the handshake selecting TLS 1.2 and the cipher suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.

javax.net.ssl|FINE|01|main|2021-03-30 14:13:29.736 UTC|Thread.java:1164|Consuming ServerHello handshake message ("ServerHello": {"server version": "TLSv1.2", "cipher suite": "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" ... })

(3) IBM JDK 1.8 + mysql‑connector‑java‑8.0.18

The older driver sends a ClientHello that already lists TLS 1.2 and a large set of cipher suites, most of which start with SSL. Because the driver does not restrict the list, the connection succeeds.

Produced ClientHello handshake message ("ClientHello": {"client version": "TLSv1.2", "cipher suites": "[SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, ..., TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, ...]" ... })

Conclusion

MySQL Connector/J 8.0.18 does not limit cipher suites, so it can negotiate with IBM JSSE2. Starting with 8.0.19 the driver restricts suites to those prefixed with TLS, while IBM’s default suites are prefixed with SSL. The mismatch leads to “no available cipher suite” errors.

Remediation Options

Solution 1 (Upgrade JDK)

Upgrade the IBM JDK to a version that includes the required TLS suites. Vendor consultation indicated this was not feasible for the project.

Solution 2 (Effective)

Set the JVM system property com.ibm.jsse2.overrideDefaultCSName=true (available from IBM JDK 1.8.0_211). In WebSphere Application Server (WAS) add a custom property:

Name: com.ibm.jsse2.overrideDefaultCSName Value: true After updating the property and restarting the server (or upgrading the JDK to 1.8.0_281), the connection succeeds.

Solution 3 (Temporary)

Disable SSL and allow public key retrieval in the JDBC URL: useSSL=false&allowPublicKeyRetrieval=true This bypasses TLS but introduces a potential MITM risk and may fail when MySQL’s authentication cache expires.

Solution 4 (Ineffective)

Force TLS 1.2 via JVM parameters (did not resolve the issue):

-Dcom.unboundid.util.SSLUtil.defaultSSLProtocol=TLSV1.2</code><code>-Dcom.unboundid.util.SSLUtil.enabledSSLProtocols=TLSV1.2