[MDEV-16627] SST silly issue, it seems verify only is concatenated with the certificate name Created: 2018-06-29  Updated: 2023-04-12  Resolved: 2023-04-11

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

Type: Bug Priority: Major
Reporter: Wagner Bianchi (Inactive) Assignee: Jan Lindström (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

Folks,

The error being discussed here is:

WSREP_SST: [INFO] Evaluating mbstream -c ${INFO_FILE} | socat -u stdio openssl-connect:db02: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.pemverify=0; RC=( ${PIPESTATUS[@]} ) (20180629 19:48:28.728)
2018/06/29 19:48:28 socat[7166] E SSL_CTX_load_verify_locations(): error:02001002:system library:fopen:No such file or directory

Just having a new fight with the SST + SSL with MariaDB Server 10.1.34. I've got this working without disabling the certificates verification executed by the latest version of socat when default enables the verify option. As the names for the new machines I'm working with are longer than before, it seems the CN cannot be tested, and that means, I'm using the sockopts under the [sst] section to disable the socat SSL verification when the certification CN (commonName) should be equal to the hostname.

By the way, I have this below on my configuration file for a new cluster:

[sst]
progress=1
time=1
encrypt = 3
tca     = /etc/my.cnf.d/certs/ca-cert.pem
tkey    = /etc/my.cnf.d/certs/server-key.pem
tcert   = /etc/my.cnf.d/certs/server-cert.pem
sockopt = "verify=0"

When having the sockopt = "verify=0", I wonder if the error about a file not found is not related to the concatenation of the option verify=0 with the name of the ca certificate...

I can tweak the script and adjust it, but, how many will have the same problem as I'm having right now?

Thanks, folks!



 Comments   
Comment by Jan Lindström [ 2023-04-11 ]

10.1 is EOL.

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