Resolving Ignition 7.9 MySQL 8.4 Authentication Errors

Where does the connection actually stop?

Follow the packet. The Ignition gateway opens a pooled JDBC connection. The MySQL driver JAR loaded in the gateway's Java 8 runtime makes a TCP connection to the MySQL 8.4 server and starts the authentication handshake. The server replies with the authentication plugin assigned to the account. When the driver does not implement that plugin, the handshake ends and the connection pool raises:

Cannot create PoolableConnectionFactory (Client does not support authentication protocol requested by server; consider upgrading MySQL client)

This message rules out layers one through four. The TCP session was established and the server answered, so routing and firewalls are working. The failure is a plugin mismatch between the driver and the account. MySQL 8.x creates accounts with caching_sha2_password by default. MySQL 8.4 ships mysql_native_password disabled. The MySQL driver used by an older 7.9 gateway predates SHA2 caching authentication, so it cannot complete the exchange.

Error text on the connection status	Hop where it stops	What to fix
Connection refused / timed out	TCP to the server port	Network path, firewall, server bind address
Client does not support authentication protocol requested by server	Auth handshake: plugin unknown to driver	Driver version or account plugin
Access denied for user	Auth handshake: credentials or host	User, password, host grant
Public key retrieval refused	SHA2 exchange without TLS	Driver connection properties

Check: Confirm that the status page shows the authentication-protocol text and not a timeout. If it shows a timeout, fix the network path first.

Which plugin is the server asking for?

Read the account definition on the 8.4 server before you change anything on either side:

SELECT user, host, plugin FROM mysql.user WHERE user = 'ignition_user';
SHOW PLUGINS;

Replace ignition_user with the account in the Ignition connection. Also check the host column. The row that matches the gateway's source address is the one the server uses. A % row and a host-specific row can have different plugins.

Check: The plugin column for the gateway's account reads caching_sha2_password. This matches the handshake failure and settles which side you change.

Should you re-enable native passwords or upgrade the driver?

There are two ways to reconcile the plugin:

Path	Change	Side effects
Re-enable native on server	Enable mysql_native_password in the server option file, restart the service, then alter the account to use it	The plugin is deprecated and disabled by default in 8.4. It carries the old client into the new server and needs a service restart.
Upgrade gateway driver	Load a newer MySQL JDBC driver that supports SHA2 and still runs on Java 8	No server change. You may need to update connection properties. Carries forward to the Ignition 8.1 migration.

In this installation, adding mysql_native_password=ON to my.ini stopped the MySQL service from restarting. On Windows, the usual causes are:

• The line is outside the [mysqld] group.
• The edited my.ini is not the file named in the service's defaults-file argument.
• The editor saved the file in an encoding the server will not parse.

The server error log in the data directory names the line it rejected. Read it before you edit again. Enabling the plugin alone does not fix anything, because you must also alter each account back to native authentication. This is why the driver path is the better choice on a system that is already migrating off 7.9.

Check: The MySQL service is running with its original, unmodified my.ini, and other clients connect normally. Leave the server alone from here on.

How do you load a SHA2-capable driver on a Java 8 gateway?

A 7.9 gateway requires Java 8. The driver must be new enough to support MySQL 8 authentication and old enough to load on Java 8. Before you download, confirm both points in the MySQL Connector/J (or MariaDB Connector/J) release notes: the minimum Java version, and support for caching_sha2_password. A driver compiled for a newer Java release will fail to load. The gateway log will show a class version error, not an authentication error.

1. Download the platform-independent Connector/J archive in the chosen release and extract the single driver JAR.
2. On the gateway web page, open Config > Databases > Drivers and edit the MySQL driver entry. Alternatively, create a new entry so the old one stays as a fallback.
3. Replace the JAR with the new file. Set the driver class name exactly as the Connector/J documentation specifies for that release, because newer releases changed the class package. Save.
4. Point the MySQL 8.4 connection at this driver entry. Leave the connections to the remaining 5.x servers on the old driver until you have tested them against the new one.

Check: The driver entry saves without error, and the gateway wrapper log shows no class-loading or unsupported-class-version exceptions for the new JAR.

Which connection settings does the new driver need?

A newer Connector/J enforces behaviour that the older driver skipped. Two points commonly block the first connection:

• SHA2 without TLS: On a non-TLS connection, the first caching_sha2_password login for an account needs the server's RSA public key. The driver refuses to fetch that key unless the public-key-retrieval connection property is enabled. The alternative is to configure TLS on the connection.
• Server time zone: Newer drivers can reject an ambiguous server time zone. Set the time zone property from the Connector/J connection-property reference, or define the time zone explicitly on the server.

Add these settings in the connection's Extra Connection Properties field, separated by semicolons. Then reinitialize the connection. Saving the connection edits does not always rebuild a pool that has already faulted.

1. Edit the connection, uncheck Enabled, and save.
2. Edit it again, re-check Enabled, and save.

In this installation, the disable/enable reinitialize step made the difference once the driver and properties were in place.

Check: Config > Databases > Connections shows the MySQL 8.4 connection as Valid, with no fault text on the status page.

How do you prove the path end to end?

A Valid status proves the handshake and nothing more. Run every layer that production traffic uses:

Test	What it proves	Pass criterion
Database Query Browser table list	Metadata calls through the new driver	Tables list without error. Gateways older than 7.9.9 show a table-listing error even after the fix, and 7.9.9 corrects it.
SELECT against a production table	Read path and permissions	Rows returned with correct timestamps
Transaction group or historian write	Insert path and store-and-forward	Rows arrive in the table and the store-and-forward quarantine stays empty
Gateway restart	First login after a server cache flush	Connection returns to Valid without manual reinitialize

Last, restart the MySQL 8.4 service during a maintenance window. The SHA2 cache clears, so the next login repeats the full key exchange. Confirm that the gateway connection faults and then recovers on its own, and that no store-and-forward data is quarantined.

FAQ