Hey there!

In the meantime I figured that this is a bug that seem to exists for at least the past 6 years [1].

I think this is a rather nasty bug because admins might not realize that their MariaDB server has lost its capability to serve TLS connections.

Given the time this bug exists it seems to be almost a feature and as such should be documented in the knowledge base, don't you think? But seriously, given the nature of this bug it would be the right thing to add a caveat about this behavior in the documentation.

Kind regards

[1] https://github.com/MariaDB/server/blob/76f4a78ba2639b5abd01a88b24a3c509c11530ce/mysql-test/main/ssl_ca.result

I don't understand. What do you mean "MariaDB loses the capability to serve TLS connections without throwing any errors or warnings"? The test verifies, specifically, that the connection will be rejected (not established without SSL), and that the server will throw an error "SSL connection error". In fact the error will be (just tried) "ERROR 2026 (HY000): SSL connection error: No such file or directory" which seems descriptive enough to me.

Ahh... yeah... now I see. Before I checked only the status output from systemctl and couldn't see any errors or warnings. Now that I checked /var/log/syslog (or /var/log/mysql/error.log) I can see the warnings:

[Warning] Failed to setup SSL

[Warning] SSL error: SSL_CTX_set_default_verify_paths failed

[Warning] SSL error: error:02001002:system library:fopen:No such file or directory

[Warning] SSL error: error:2006D080:BIO routines:BIO_new_file:no such file

[Warning] SSL error: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib

And also "show variables like 'have_ssl'" returns: DISABLED.

Okay, we have logging, that's soothing. And I'm sorry for having made such a fuzz. I'm trying to be more thorough the next time I open a ticket.

But may I add that I find the mariadb CLI client behavior a little counter intuitive. When connecting with the --ssl option the connection gets established no matter what, even if the server is not able to serve TLS connections.

I would rather expect the client to connect via TLS if it's available (also without explicitly setting the --ssl option). And refuse to connect if the --ssl option was given and the server can't serve TLS.

It seems that, as of now, there is an option missing on the client-side that refuses to connect to a server if the server can't serve TLS connections.

Or did I just miss it (again)? If not, shall I create a feature request?

First, my reply was about mariadb CLI, which tells the user "ERROR 2026 (HY000): SSL connection error: No such file or directory" if ssl-ca is invalid. I see you that meant the server having invalid ssl-ca. In that case, indeed, it'll be in the error log.

Unfortunately, historically --ssl meant "try SSL with fallback to non-encrypted". I think it's a rather meaningless behavior, but that's how it was for 20 years and we cannot just change it. On the other hand, just "ssl" doesn't mean much — you need to verify the certificate otherwise man-in-the-middle can replace it and your "ssl" connection will be encrypted, but completely unprotected. That is, additionally you need to specify ssl-verify-server-cert. And in that case the client, indeed, will refuse to connect if the server can't serve TLS.

Thank you for your explanation. Indeed, that's unfortunate. Depending on the network situation, a non-encrypted connection is as bad as a man-in-the-middle. But how about making --ssl the default behavior for mariadb CLI? I'd reckon that unverified TLS is preferable to no TLS. Wouldn't it make the mariadb CLI a little bit more secure by default?

Yes, I think it's possible. It won't exactly make MariaDB more secure by default, but if the DBA has configured SSL on the server and MitM is not a concern, then it'll make the CLI more secure indeed.

I'm happy to hear/read this. I created a feature request to make --ssl the default for the client CLI. Thank you & kind regards!