How to fix CR_UNKNOWN_ERROR (2000): Unknown MySQL error in MySQL
CR_UNKNOWN_ERROR (2000) is a catch-all MySQL client error that fires before the connector can deliver a more specific message. It usually appears when the connection or authentication handshake is aborted early—for example, when TLS is required but the client and server cannot agree on a cipher stack or when an authentication plugin terminates the session without reporting a normal SQLSTATE. Because no additional diagnostics are printed, the client sees only "Unknown MySQL error" and the server log typically contains nothing more than a brief warning or a reverse DNS lookup entry.
Quick fix
Fixes CR_UNKNOWN_ERROR (2000): Unknown MySQL error
mysql --version
mysql -h your.host -u app -p
# After the password prompt you will see ERROR 2000 (HY000): Unknown MySQL error- Reproduce the failure and capture client/server versions
- Inspect authentication plugin and SSL stack compatibility
- Switch the account to mysql_native_password or match TLS providers
- Force SSL mode and retest the connection
mysql --versionmysql -h your.host -u app -p# After the password prompt you will see ERROR 2000 (HY000): Unknown MySQL errorCR_UNKNOWN_ERROR (2000): Unknown MySQL error
What this error means
The MySQL client error list documents 2000 (CR_UNKNOWN_ERROR) as "Unknown MySQL error," meaning the client library failed internally before it could decode a richer server reply. This happens when the connection state is invalid for the requested function, the TLS handshake is abruptly dropped, or the authentication plugin refuses to proceed. In practice, it often masks a TLS/authentication mismatch: the client and server start the handshake, then the process ends before any SQLSTATE or error message is transmitted. The only symptom is the generic 2000 code. Unless you look at the network handshake or align the TLS providers, the client stays blind to the root cause.
Typical symptoms
- MySQL command-line client prints "ERROR 2000 (HY000): Unknown MySQL error" immediately after entering the password
- The same credentials work from another client that uses a different build or OS
- Reverse DNS or SSL warnings appear in the server log, but no SQLSTATE or stack trace follows
- Connection requests hang briefly and then abort with no additional context
- Applications report disconnections before the first SQL statement is delivered
- Using the mysql client with the --ssl-mode flag does not surface a clearer error
Common causes
- sha256_password authentication requires an encrypted handshake and fails cleanly when the client and server use different SSL providers (e.g., OpenSSL vs yaSSL)
- The client binary lacks TLS support while the user still relies on sha256_password, so the authentication plugin terminates before sending an error code
- Server is configured to require SSL for the account but the client cannot negotiate a cipher suite, leaving CR_UNKNOWN_ERROR as the only indication
- Client and server have incompatible protocol versions or compile-time options that corrupt the handshake buffer
- There is a bug in the MySQL client (see bug 75867) triggered by mismatched SSL implementations when sha256_password is selected
How to fix "CR_UNKNOWN_ERROR (2000): Unknown MySQL error"
Run the mysql client from the failing host and note the error message and binary details:
mysql --version
mysql -h your.host -u app -p
# After the password prompt you will see ERROR 2000 (HY000): Unknown MySQL errorCheck the server log tail (/var/log/mysql/error.log or /var/log/mysqld.log) to confirm there is only a brief reverse-DNS warning and no SQLSTATE. This proves the handshake died before the server could send a descriptive error.
Connect with a working client (or from the server itself) and run:
SELECT user, host, plugin FROM mysql.user WHERE user = 'app';If the plugin is sha256_password, ensure both client and server were built with the same TLS provider. On each host run:
mysql --help | grep -i SSL
ldd $(which mysql) | grep -i ssl
mysqld --versionMixing yaSSL and OpenSSL builds is a well-known trigger (see DBA Stack Exchange report and bug 75867), because the sha256_password plugin hands the password across a TLS channel that must agree on the cryptographic library.
If you cannot rebuild the client with the same SSL stack, fall back to mysql_native_password for that user:
ALTER USER 'app'@'%' IDENTIFIED WITH mysql_native_password BY 'secret';
FLUSH PRIVILEGES;Alternatively, install a mysql client compiled with OpenSSL to mirror the server, or rebuild both mysqld and the connector with the same TLS provider so the sha256_password handshake can complete.
Reconnect from the problem host using explicit SSL parameters to verify the fix:
mysql --ssl-mode=REQUIRED --ssl-ca=/path/to/ca.pem -h your.host -u app -pIf the connection succeeds, the handshake is healthy. If it still fails, double-check you are pointing at the same certificate files the server uses and that any middleboxes are not dropping packets during the TLS negotiation.
Advanced notes
Bug 75867 documents how sha256_password fails when the server and client are built with a different TLS library: the client hangs in the TLS handshake and then returns CR_UNKNOWN_ERROR. When both sides use OpenSSL or when you switch the account to mysql_native_password, the connection works again. Always align the TLS provider and rebuild your connector if you depend on sha256_password, or choose mysql_native_password to avoid the opaque 2000 error entirely.
Frequently asked questions
- What does "CR_UNKNOWN_ERROR (2000): Unknown MySQL error" mean?
- The MySQL client error list documents 2000 (CR_UNKNOWN_ERROR) as "Unknown MySQL error," meaning the client library failed internally before it could decode a richer server reply. This happens when the connection state is invalid for the requested function, the TLS handshake is abruptly dropped, or the authentication plugin refuses to proceed. In practice, it often masks a TLS/authentication mismatch: the client and server start the handshake, then the process ends before any SQLSTATE or error message is transmitted.
- How do I fix "CR_UNKNOWN_ERROR (2000): Unknown MySQL error"?
- CR_UNKNOWN_ERROR (2000) is a catch-all MySQL client error that fires before the connector can deliver a more specific message. It usually appears when the connection or authentication handshake is aborted early—for example, when TLS is required but the client and server cannot agree on a cipher stack or when an authentication plugin terminates the session without reporting a normal SQLSTATE. Because no additional diagnostics are printed, the client sees only "Unknown MySQL error" and the server log typically contains nothing more than a brief warning or a reverse DNS lookup entry.
- What causes "CR_UNKNOWN_ERROR (2000): Unknown MySQL error"?
- sha256_password authentication requires an encrypted handshake and fails cleanly when the client and server use different SSL providers (e.g., OpenSSL vs yaSSL) The client binary lacks TLS support while the user still relies on sha256_password, so the authentication plugin terminates before sending an error code Server is configured to require SSL for the account but the client cannot negotiate a cipher suite, leaving CR_UNKNOWN_ERROR as the only indication
- Is the "CR_UNKNOWN_ERROR (2000): Unknown MySQL error" error serious?
- It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.