1

Since moving from MySQL to a newer MariaDB installation on Debian 9, I a struggling with SSL connections.

I have created a CA certificate and installed it on both server and client. I then have created server and client keys and certificates that I signed with the CA certificate.

What works:

I can connect from the client to the server with the mysql client without SSL connections.

I can verify the client certificate with openssl:

$ openssl verify MariaDB_client.crt 

MariaDB_client.crt: OK

I understand that MariaDB uses yaSSL, but this still shows that the certificates and CA are correct, I think.

On the server, I have:

MariaDB> show global variables like '%ssl%';
+---------------------+--------------------------------------+
| Variable_name       | Value                                |
+---------------------+--------------------------------------+
| have_openssl        | NO                                   |
| have_ssl            | YES                                  |
| ssl_ca              | /etc/mysql/conf.d/MariaDB_ca.crt     |
| ssl_capath          |                                      |
| ssl_cert            | /etc/mysql/conf.d/MariaDB_server.crt |
| ssl_cipher          |                                      |
| ssl_crl             |                                      |
| ssl_crlpath         |                                      |
| ssl_key             | /etc/mysql/conf.d/MariaDB_server.key |
| version_ssl_library | YaSSL 2.4.4                          |
+---------------------+--------------------------------------+

What does not work:

If I add a .my.cnf file with the following content to the users $HOME directory...

[client]
ssl-ca=/--path--/MariaDB_ca.crt
ssl-cert=/--path--/MariaDB_client.crt
ssl-key=/--path--/MariaDB_client.key

...the connection fails with:

ERROR 2026 (HY000): SSL connection error: unable to verify peer checksum

In the server log, I find (not sure whether this is related):

[Warning] IP address 'ip.of.connecting.client' could not be resolved: Name or service not known

My questions:

  • How can I narrow down/debug this connection problem?

  • I found conflicting information about whether I should use the same or different CN for the server and client certificates. Currently, I use the same CN.

  • Are there particular access rights required for the certificates?

4
  • Alternatively, try dba.stackexchange.com
    – Rick James
    Mar 17, 2019 at 17:06
  • On DBA it could be a good idea too like @RickJames told, but please don't double post, just flag for a move if you want a move. Thanks you
    – yagmoth555
    Mar 18, 2019 at 13:34
  • Ok, I understand. How do I "flag for a move"?
    – user52366
    Mar 18, 2019 at 16:28
  • Click under the question flag, and enter that you want a move, but as it's answered now, I no longer think it's a good move IMO
    – yagmoth555
    Mar 18, 2019 at 16:52

1 Answer 1

2

After many hours of trying, things now finally work.

The crucial step was to use the server's IP as common name (CN) in the server certificate (actually the csr that signed then gives the certificate), not an arbitrary host name as some instructions suggest. A lot of sources I found were contradicting in this respect.

I am using MariaDB as distributed with Debian 9, linked to the yaSSL library. Maybe things are different with openssl. They certainly are different from MySQL.

1
  • Using an IP as the CN is bad form, violates the RFC's, and can be difficult to maneuver. A better solution would be to either set the CN to be a valid fqdn with a DNS address, or just set it to a URL-valid name that points to localhost in your /etc/hosts file.
    – Ryder
    Mar 19, 2019 at 10:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .