[MDEV-32765] Galera SST using rsync over stunnel certificate verification bug Created: 2023-11-10  Updated: 2023-11-10

Status: Open
Project: MariaDB Server
Component/s: Galera SST
Affects Version/s: 10.5.21
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Richard Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: sst
Environment:

Server version: 10.5.21-MariaDB-0+deb11u1 Debian 11
uname: Linux 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29) x86_64 GNU/Linux



 Description   

When using rsync over stunnel with a signed cert and CA chain, the stunnel client connection fails with SSL certificate verification error.

After debug the issue, I found that the stunnel.conf file created on the donor side have a bad
checkHost value of "CN ":

key = /etc/ssl/xxx.pem
cert = /etc/ssl/xxx.pem
CAfile = /etc/ssl/xxx.pem
 
foreground = yes
pid = /var/lib/mysql/stunnel.pid
debug = warning
client = yes
connect = x.x.x.x:4444
TIMEOUTclose = 0
verifyChain = yes
checkHost = CN 

The issue seems to be caused by a problem parsing common name from the cert.
This patch fixes the problem (cut field number changed from 2 to 3):

--- wsrep_sst_rsync	2023-07-23 23:26:58.000000000 +0200
+++ wsrep_sst_rsync_fix	2023-11-09 17:34:09.380952730 +0100
@@ -856,7 +856,7 @@
                 exit 42
             fi
             CN=$("$OPENSSL_BINARY" x509 -noout -subject -in "$SSTCERT" | \
-                 tr ',' '\n' | grep -F 'CN =' | cut -d '=' -f2 | sed s/^\ // | \
+                 tr ',' '\n' | grep -F 'CN =' | cut -d '=' -f3 | sed s/^\ // | \
                  sed s/\ %//)
         fi
         MY_SECRET="$(wsrep_gen_secret)"

OpenSSL> version
OpenSSL 1.1.1w  11 Sep 2023

With this patch the stunnel.conf is correct, and certificate verification works fine:

key = /etc/ssl/xxx.pem
cert = /etc/ssl/xxx.pem
CAfile = /etc/ssl/xxx.pem
 
foreground = yes
pid = /var/lib/mysql/stunnel.pid
debug = warning
client = yes
connect = x.x.x.x:4444
TIMEOUTclose = 0
verifyChain = yes
checkHost = example.com


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