[MDEV-31934] CHANGE MASTER does not pick up TLS defaults from config file as documented Created: 2023-08-16  Updated: 2023-11-23  Resolved: 2023-09-04

Status: Closed
Project: MariaDB Server
Component/s: Documentation, Replication, SSL
Affects Version/s: 10.6.15, 11.1.3
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Hartmut Holzgraefe Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Problem/Incident
causes MXS-4718 Add replication_custom_options to ena... Closed

 Description   

According to https://mariadb.com/kb/en/replication-with-secure-connections/#setting-tls-client-options-in-an-option-file TLS certificate options like MASTER_SSL_CA, MASTER_SSL_CERT and MASTER_SSL_KEY can either be set explicitly in a CHANGE MASTER command, or will be fetched from respective options in the [client] or [client-mariadb] section of the config file(s).

I could not get this to work (tried with 10.6 and 11.1 so far), and looking at the server code I don't see yet how it could possibly use any client section settings either.

I verified that the client options are set correctly by setting up:

[client-mariadb]
ssl
ssl-ca=/vagrant/files/ssl/ca-cert.pem
ssl-cert=/vagrant/files/ssl/slave-1-cert.pem
ssl-key=/vagrant/files/ssl/slave-1-key.pem

and creating a replication user requiring to-way/mutual TLS using:

CREATE USER repl@'%' IDENTIFIED BY 'Secret23!' REQUIRE x509;
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@'%';

I verified that from the slave host I can connect to the master using that user, and that it fails when not reading the option file(s), due to the client no longer offering a client certificate for two-way TLS:

root@slave-1:~# mysql --user=repl --password=Secret23! --host=master --execute="SHOW STATUS LIKE 'Ssl_Version'"
 
+---------------+---------+
| Variable_name | Value   |
+---------------+---------+
| Ssl_version   | TLSv1.2 |
+---------------+---------+
 
root@slave-1:~# mysql --no-defaults --user=repl --password=Secret23! --host=master --execute="SHOW STATUS LIKE 'Ssl_Version'"
 
ERROR 1045 (28000): Access denied for user 'repl'@'slave-1' (using password: YES)

Same problem when setting up the slave with just

CHANGE MASTER TO MASTER_HOST='master'
               , MASTER_USER='repl'
               , MASTER_PASSWORD='Secret23!'
               , MASTER_USE_GTID=slave_pos
               , MASTER_SSL=1;
START SLAVE;
SHOW SLAVE STATUS\G
 
[...]
                 Last_IO_Errno: 1045
                 Last_IO_Error: error connecting to master 'repl@master:3306' - retry-time: 60  maximum-retries: 100000  message: Access denied for user 'repl'@'slave-1' (using password: YES)
[...]

When explicitly adding

               , MASTER_SSL_CA='/vagrant/files/ssl/ca-cert.pem'
               , MASTER_SSL_KEY='/vagrant/files/ssl/slave-1-key.pem'
               , MASTER_SSL_CERT='/vagrant/files/ssl/slave-1-cert.pem'

the slave can start just fine.

I also verified with WireShark that in the failed case no client certificate was offered to the server during TLS handshake.



 Comments   
Comment by Hartmut Holzgraefe [ 2023-09-04 ]

Why is this closed now?

Comment by Sergei Golubchik [ 2023-09-04 ]

because the mismatch between the documentation and the implementation is fixed, the documentation no longer claims that the server reads client sections of my.cnf

Generated at Thu Feb 08 10:27:34 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.