This seems to be happen only using TLSv1.3 where client certificate is checked after handshake.

Server:
SSL_accept() returns -1 and SSL_get_error returns SSL_ERROR_SSL. Instead of retrieving the OpenSSL error, this error is handled as a protocol error (errno=EPROTO):

(gdb) p ssl_error

$1 = 1

(gdb) p ERR_error_string(1, NULL)

$2 = 0x7ffff7cfb1a0 <buf> "error:00000001:lib(0):func(0):reason(1)"

(gdb) p ERR_error_string(ERR_peek_error(), NULL)

$3 = 0x7ffff7cfb1a0 <buf> "error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed"

On client side SSL_connect() returns success (=1)

Partial fix pushed for Connector/C - server still needs to be fixed. (reassigning to wlad)

Only client-side solution is OK I guess. If this is really fixed on the client, georg, please indicate the versions where it would be fixed, and feel free to close

I tend to disagree, this is not the only connector in the world, and there even be client applications using Connector/C but don't forward library error messages properly.

So wearing my "I have to support all of this" hat I'd very much like to see the server report actual reasons for (This connection closed normally without authentication).

wlad I didn't close it, since it needs to be fixed in server. The information":tls_process_client_certificate:certificate verify failed" is available and should be written to logs.
Since TLSv1.3 alerts can be send after initial handshake - so read/write error is not a socket error ony, but also an TLS alert. If SSL_get_error() returns SSL_ERROR_SSL server should retrieve the errormsg and write it to log.