[Proposal]: Return a clearer error when account SSL requirements are not met

[Taeknology]

Proposal

MySQL should distinguish an invalid password from a connection rejected specifically because the account's SSL requirements are not satisfied.

Currently, both cases can return:

ERROR 1045 (28000): Access denied for user ... (using password: YES)

using password: YES only indicates that the client supplied a password. It does not mean that the password was incorrect.

Why this matters

I work as a DBA and am currently helping teams prepare for the MySQL 8.0 end-of-life transition. During this work, I repeatedly receive connection-failure inquiries where developers assume that Access denied ... (using password: YES) means the password is incorrect.

In many cases, investigating the password is only the beginning. The actual cause may involve SSL requirements, authentication plugins, TLS configuration, or connector compatibility. Because these failures can appear identical to clients, application developers and DBAs must repeatedly inspect secrets, account definitions, connector settings, and server-side diagnostics to determine the real cause.

As authentication and transport requirements become more diverse in newer MySQL versions, this ambiguity creates growing operational and support overhead.

A clearer client-visible error would allow developers to investigate the correct configuration immediately, reducing unnecessary password rotations, repeated support requests, and time-consuming coordination between application teams and DBAs.

Requested behavior

Keep the existing generic access-denied response for incorrect credentials and unknown accounts.

When a connection is rejected specifically because the account's SSL requirements are not satisfied, return a distinct and actionable error, for example:

Account SSL requirements were not satisfied.

The failure should have a stable error code so clients and connectors can identify it without parsing message text.

Security considerations

Invalid credentials and unknown accounts should continue receiving the generic access-denied response.

The new error should identify only the broad SSL-policy failure. It should not expose certificate details, expected subjects or issuers, or other sensitive account configuration.

Implementation feasibility

MySQL already distinguishes credential, authentication-plugin, handshake, and SSL failures internally. SSL failures are also counted separately through Performance Schema.

The required failure category therefore already exists in the server. This proposal asks that the category be preserved in the client response instead of being converted to the generic 1045 error.

Expected benefits

• Shorter connection-failure investigations
• Fewer unnecessary password rotations or account changes
• Clearer guidance for application and connector developers
• Better alignment between client errors and MySQL's existing internal diagnostics
• Stable error handling without message-text parsing

Related issue

MySQL Bug #112581 reported the same SSL-versus-password ambiguity but was closed because it did not include a reproducible SQL and CLI test case.

A minimal MySQL 9.7 reproduction can be provided with this proposal.

[Taeknology]

I reproduced this on the current mysql/mysql-server trunk:

• MySQL 26.7.0-debug
• Commit 06a5c1c99c377fc41b2eba1ea244e8b220bdc3c8
• Linux x86_64

CREATE USER 'ssl_user'@'127.0.0.1'
  IDENTIFIED BY 'correct_pw'
  REQUIRE SSL;

TLS with the correct password succeeds:

mysql -h127.0.0.1 -P33079 -ussl_user -pcorrect_pw --ssl-mode=REQUIRED

The same correct password without TLS:

mysql -h127.0.0.1 -P33079 -ussl_user -pcorrect_pw --ssl-mode=DISABLED

returns:

ERROR 1045 (28000): Access denied for user 'ssl_user'@'localhost'
(using password: YES)

An incorrect password over TLS returns the same client-visible error.

The account SSL check in sql/auth/sql_authentication.cc records the failure as
Host_errors::m_ssl, but routes it through login_failed_error(), which returns
ER_ACCESS_DENIED_ERROR.

Maintainer guidance on whether this should use a new dedicated error code would
be appreciated before preparing a patch.

[jfg956]

Return a clearer error when account SSL requirements are not met

I am not sure this is the right approach...

MySQL should distinguish an invalid password from a connection rejected specifically because the account's SSL requirements are not satisfied.

...I agree with above, but I do not agree with exposing this to the user. Let's step back a little to fully understand my position.

It is considered a general best practice to not expose users to error message like below:

• account does not exist
• password is invalid
• user is not allowed to connect from this ip
• ...and more...

The reason for above is that such error messages allow an attacker to gather data on the system he is connecting to. And for this reason, the exposed message should be general and always the same, like "Access denied".

This does not mean a DBA should not have observability for these, but users should not.

A way to provide a DBA with such observability is logs, but they can quickly become filled with useless data in case of a client misconfiguration or an attack. Also, verbose logs enable an attacker to fill the disk, so alternatives should be explored.

I would suggest counters with different granularities. MySQL already provide Global Statuses like Aborted_clients, Aborted_connects, and [Connection_errors_xxx](https://dev.mysql.com/doc/refman/8.4/en/server-status-variables.html#statvar_Connection_errors_xxx). There is also the host_cache Table. These could be extent to include counters providing the feature discussed here (if not already there). We could also have a "user_cache table" to include per user errors.

[github-actions]

💬 A discussion has been created in Developer / DBA Experience:

#128

Please continue community discussion there while this issue remains the authoritative tracking item.