MySQL 8.0 caching_sha2_password and legacy Connector/J: retaining mysql_native_password at the authentication boundary
0 reputation · 14 Sept 2026, 20:56 UTC
0 reputation · 14 Sept 2026, 20:56 UTC
MySQL Server 8.0 introduced caching_sha2_password as the default authentication plugin, shifting the handshake boundary for legacy client connectors. Applications using Connector/J versions before 8.0, or other drivers that predate this plugin, cannot complete full authentication unless they negotiate an SSL/TLS connection or explicitly request an RSA key exchange. The alternative path is mysql_native_password, which those older clients understand natively, but that plugin is deprecated and recent MySQL 8.x releases have begun disabling it by default, though this behavior varies by distribution and minor version.
Administrators face an unresolved compatibility decision: retain mysql_native_password to avoid immediate connection failures during a phased client upgrade, or disable it to enforce the newer authentication path and accept that legacy connectors must either move to TLS everywhere or be replaced. The tradeoff is complicated by the fact that RSA key exchange over an untrusted network introduces man-in-the-middle exposure unless server certificates are validated, and deprecation timelines for legacy authentication plugins differ across MySQL series and distributions.
What is the safest boundary configuration when a MySQL 8.x server must support both modern and legacy client drivers simultaneously? Should mysql_native_password remain enabled for specific accounts during migration, or is disabling it and requiring TLS the only defensible long-term posture? How should teams assess which minor-version behavior applies when recent releases change the default plugin status?
35275 reputation · 14 Sept 2026, 21:17 UTC
Keep mysql_native_password enabled only for a small set of legacy accounts during migration, and require TLS for those accounts if the clients support it. Modern accounts should use caching_sha2_password with TLS enforced. Disabling mysql_native_password globally before legacy Connector/J clients are upgraded or confirmed to support TLS with RSA key exchange will break connections. Requiring TLS for all accounts is the defensible long-term posture, not the immediate starting point.
default_authentication_plugin to caching_sha2_password.mysql_native_password is deprecated but still available in MySQL 8.0; its status in later 8.x minors varies by distribution.caching_sha2_password; they need mysql_native_password or TLS with RSA key exchange.caching_sha2_password over an unencrypted connection fails unless RSA key exchange is negotiated, and unverified RSA exchange exposes the connection to man-in-the-middle attacks.mysql.user; the server default is controlled by default_authentication_plugin.SHOW VARIABLES LIKE 'default_authentication_plugin';SELECT User, Host, plugin FROM mysql.user;ssl-ca, ssl-cert, and ssl-key in the server option file, then restart.ALTER USER 'legacy_app'@'10.0.%' IDENTIFIED WITH 'mysql_native_password' BY 'password' REQUIRE SSL; Restrict the host to the internal legacy network segment.ALTER USER 'modern_app'@'%' IDENTIFIED WITH 'caching_sha2_password' BY 'password' REQUIRE SSL;mysql_native_password but limit it to a trusted network and plan a client upgrade.mysql_native_password after migration. Once no legacy connector requires it, change those accounts to caching_sha2_password and consider disabling the plugin globally if the build allows it.Run
SELECT @@version; and consult the release notes for that exact 8.x minor. Some distributions ship with mysql_native_password enabled by default; explicitly set default_authentication_plugin = 'caching_sha2_password' in the server configuration to avoid accidental fallback. Treat any change in deprecation status as unverified until confirmed in the release notes for the installed patch level.
One detail changes the recommendation: can the legacy Connector/J clients establish TLS and validate the server certificate? If they cannot, a temporary mysql_native_password account on an isolated network is the only compatible fallback. If they can, move them to caching_sha2_password with REQUIRE SSL now.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.