[MDEV-15568] SST + SSL/TLS broken due to socat CN check Created: 2018-03-14  Updated: 2019-08-28  Resolved: 2018-08-07

Status: Closed
Project: MariaDB Server
Component/s: Galera SST
Affects Version/s: 10.1.28
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Wagner Bianchi (Inactive) Assignee: Jan Lindström (Inactive)
Resolution: Not a Bug Votes: 2
Labels: None
Environment:

CentOS 7.2

Issue Links:
Relates
relates to MDEV-16219 mariadb ssl_rsa_setup maintenance too... Open

 Description   

Folks,

Configuring a running MariaDB Cluster 10.1.28 with self-signed SSL certs with different CNs cause the SST break due to socat 1.7.3 which has extra certificate check introduced:

WSREP_SST: [INFO] Evaluating mbstream -c ${INFO_FILE} | socat -u stdio openssl-connect:192.168.50.15:4444,cert=/etc/my.cnf.d/certs/server-cert.pem,key=/etc/my.cnf.d/certs/server-key.pem,cafile=/etc/my.cnf.d/certs/ca-cert.pem; RC=( ${PIPESTATUS[@]} ) (20180313 21:08:36.885)
 
2018/03/13 21:08:36 socat[25873] E certificate is valid but its commonName does not match hostname

Is there any treatment that can be done to avoid this issue, adding, e.g. --verify=0?

After generating the certificates:

$ openssl verify -CAfile ca-cert.pem server-cert.pem client-cert.pem
 
server-cert.pem: OK
 
client-cert.pem: OK



 Comments   
Comment by Wagner Bianchi (Inactive) [ 2018-05-04 ]

Folks,

I managed to create certificates in a way it can comply with the new verify option enabled by default within the new socat version. This is a matter of creating the CA and the client certificates ion one of the server/nodes, part of the cluster and rsync them to all other nodes. Go to each of the nodes and create local server cert based on the previously created CA certificate. Doing this way, you can fill up the CN or CommonName field during the process of the certificate creation with the server name. Wildcard certificates are not well supported as I tested that before coming to this solution.

#: success logs
 
WSREP_SST: [INFO] WARNING: Stale temporary SST directory: /var/lib/mysql//.sst from previous state transfer. Removing (20180504 21:29:55.652)
 
WSREP_SST: [INFO] Proceeding with SST (20180504 21:29:55.657)
 
WSREP_SST: [INFO] Evaluating socat -u openssl-listen:4444,reuseaddr,cert=/etc/my.cnf.d/certs/server-cert.pem,key=/etc/my.cnf.d/certs/server-key.pem,cafile=/etc/my.cnf.d/certs/ca-cert.pem stdio | mbstream -x; RC=( ${PIPESTATUS[@]} ) (20180504 21:29:55.659)
 
WSREP_SST: [INFO] Cleaning the existing datadir and innodb-data/log directories (20180504 21:29:55.661)
 
removed ‘/var/lib/mysql/mariadb-bin.index’
 
removed ‘/var/lib/mysql/aria_log_control’
 
removed ‘/var/lib/mysql/aria_log.00000001’
 
removed ‘/var/lib/mysql/ibdata1’
 
removed ‘/var/lib/mysql/ib_logfile1’
 
removed ‘/var/lib/mysql/ib_logfile0’
 
removed ‘/var/lib/mysql/mariadb-bin.000001’
 
removed ‘/var/lib/mysql/mysql.sock’
 
removed ‘/var/lib/mysql/mariadb-bin.state’
 
WSREP_SST: [INFO] Waiting for SST streaming to complete! (20180504 21:29:55.717)

So, with that said, we can close this JIRA, thanks!

Comment by Mathew Winstone [ 2019-08-28 ]

If you follow the docs and pass 'tca' with encrypt 3 it would appear that triggers socat to validate the certs. If you omit 'tca' it seems to just use the certificates.

I'm using 10.3 and my state transfers appear to be working so long as I omit tca.

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