MySQL 5.7 Upgrade Failure Caused by Default SSL Enablement and JDBC useSSL Parameter Misconfiguration

Introduction

The author, a DBA from China Mobile's Information Platform Department, describes a painful MySQL upgrade from 5.7.27 to 5.7.30 (actually focusing on the differences between 5.7.27 and 5.7.28) that resulted in application page errors and a "Bad handshake" note in the MySQL error log.

Phenomenon

After upgrading, the application could not connect; the MySQL error log showed a 2020-05-05T22:10:57.976402+08:00 2 [Note] Bad handshake entry. The JDBC URL contained useSSL=true, which was later changed to useSSL=false and the problem disappeared.

Analysis

Tests were performed on both 5.7.27 and 5.7.28 installations:

spring.datasource.url=jdbc:mysql://192.168.199.198:3307/springbootdb?useUnicode=true&useSSL=true&characterEncoding=utf8

On 5.7.27 the SSL variables were all DISABLED and the connection succeeded even with useSSL=true. On 5.7.28 the variables changed to YES and certificate files (ca.pem, server‑cert.pem, etc.) were automatically generated, causing the JDBC driver to attempt an SSL handshake.

Packet captures ( tcpdump) showed encrypted traffic only after the upgrade, and Tomcat logs displayed SSL‑related warnings such as:

"Establishing SSL connection without server's identity verification is not recommended… You need either to explicitly disable SSL by setting useSSL=false, or set useSSL=true and provide a truststore for server certificate verification."

The verifyServerCertificate parameter (default true) also contributed to the failure because no truststore was provided.

Root Cause

Starting with MySQL 5.7.28, the server is built with OpenSSL and enables SSL by default (parameter --auto-generate-certs is ON). The server automatically creates a set of certificate files ( ca-key.pem, ca.pem, server‑cert.pem, server‑key.pem, …) in the data directory. In earlier versions (5.7.27 and before) SSL was compiled with yaSSL and disabled unless the administrator manually generated certificates with mysql_ssl_rsa_setup. Consequently, the same JDBC URL behaved differently across versions.

Solutions

Disable SSL globally by adding skip_ssl (or skip_ssl) to the [mysqld] section of my.cnf.

Turn off automatic certificate generation with auto_generate_certs=OFF.

Remove the useSSL=true flag or set it to false in the JDBC URL.

If SSL is required, provide a proper truststore and keep verifyServerCertificate=true.

Deleting individual certificate files is unreliable because MySQL may regenerate them on restart, especially after a backup/restore.

Recommendation

For environments that previously had SSL disabled, add the following to my.cnf before upgrading:

[mysqld]
skip_ssl

This prevents the server from enabling SSL automatically and avoids the handshake failure caused by the legacy useSSL=true setting.

Conclusion

The article shares a real‑world case of JDBC configuration pitfalls during a MySQL upgrade, highlights undocumented default parameter changes (OpenSSL default, auto‑generated certificates), and advises thorough pre‑upgrade testing of SSL‑related variables.