[MDEV-20123] MDB 10.4.7 2-way (client<->server) TLS fails validation if remote connection & 'ssl_verify_server_cert' enabled Created: 2019-07-22  Updated: 2022-06-03  Resolved: 2022-06-03

Status: Closed
Project: MariaDB Server
Component/s: SSL
Affects Version/s: 10.4.6, 10.4
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: pgnd Assignee: Oleksandr Byelkin
Resolution: Not a Bug Votes: 0
Labels: None


 Description   

I run MDB,

mysqld -V
 
	mysqld  Ver 10.4.7-MariaDB-log for Linux on x86_64 (Source distribution)

on 2 machines on the same LAN, 'host1' & 'host2'

MDB was config'd/built with

openssl version
 
	OpenSSL 1.1.1c  28 May 2019

ssl certs for host1 & host2, client & server usage, are locally generated, self-signed by my own CA.

@host1,

openssl verify \
 
 -CAfile /srv/ssl/myCA/ca.crt.pem \
 
 /srv/ssl/host1/server.ec.crt.pem \
 
 /srv/ssl/host1/client.ec.crt.pem
 
	...
 
	/srv/ssl/myCA/ca.crt.pem: OK
 
	/srv/ssl/host1/server.ec.crt.pem: OK
 
	/srv/ssl/host1/client.ec.crt.pem: OK

@host2

openssl verify \
 
 -CAfile /srv/ssl/myCA/ca.crt.pem \
 
 /srv/ssl/host2/server.ec.crt.pem \
 
 /srv/ssl/host2/client.ec.crt.pem
 
	...
 
	/srv/ssl/myCA/ca.crt.pem: OK
 
	/srv/ssl/host2/server.ec.crt.pem: OK
 
	/srv/ssl/host2/client.ec.crt.pem: OK

each machine is similarly config'd.

host1 ssl config is,

cat /usr/local/etc/mariadb/conf.d/ssl.cnf
 
	[mysqld]
 
	tls_version = TLSv1.3
 
	ssl_cert = /srv/ssl/host1/server.ec.crt.pem
 
	ssl_key  = /srv/ssl/host1/server.ec.key.pem
 
	ssl_ca   = /srv/ssl/myCA/ca.crt.pem
 
 
 
	[client]
 
	tls_version = TLSv1.3
 
	ssl_cert = /srv/ssl/host1/client.ec.crt.pem
 
	ssl_key  = /srv/ssl/host1/client.ec.key.pem
 
	ssl_ca   = /srv/ssl/myCA/ca.crt.pem
 
	ssl_verify_server_cert

simlarly for host2.local

connect with `mysql` on host1/localhost, status is,

MariaDB [(none)]> status
 
	--------------
 
	mysql  Ver 15.1 Distrib 10.4.7-MariaDB, for Linux (x86_64) using readline 5.1
 
	Connection id:          10
 
	Current database:
 
	Current user:           root@localhost
 
	SSL:                    Cipher in use is TLS_CHACHA20_POLY1305_SHA256
 
	Current pager:          /usr/bin/less
 
	Using outfile:          ''
 
	Using delimiter:        ;
 
	Server:                 MariaDB
 
	Server version:         10.4.7-MariaDB-log Source distribution
 
	Protocol version:       10
 
	Connection:             Localhost via UNIX socket
 
	Server characterset:    utf8mb4
 
	Db     characterset:    utf8mb4
 
	Client characterset:    utf8mb4
 
	Conn.  characterset:    utf8mb4
 
	UNIX socket:            /run/mariadb/mariadb.sock
 
	Uptime:                 36 min 1 sec
 
	Threads: 8
 
	Questions: 12
 
	Slow queries: 0
 
	Opens: 16
 
	Flush tables: 1
 
	Open tables: 10
 
	Queries per second avg: 0.005
 
	--------------

NOTE ssl + TLSv13 cipher in use.

remote connect with `mysql` on host1->host2 FAILs@host1

mysql -vvv -h host2.pgnd.lan
 
	ERROR 2026 (HY000): SSL connection
 
	error: Validation of SSL server certificate failed

@ host2

tail -f /var/log/mariadb/mariadb-err.log
 
	2019-07-22 14:55:23 19 [Warning] Aborted connection 19 to db: 'unconnected' user: 'unauthenticated' host: '10.1.1.1' (This connection closed normally without authentication)

editing @host1 ssl config,

edit /usr/local/etc/mariadb/conf.d/ssl.cnf
 
	...
 
	[client]
 
	...
 
-        ssl_verify_server_cert
 
+        #ssl_verify_server_cert

now, remote connect with `mysql` on host1->host2 WORKs

mysql -vvv -h host2.pgnd.lan
 
    MariaDB [(none)]> status
 
		--------------
 
		mysql  Ver 15.1 Distrib 10.4.7-MariaDB, for Linux (x86_64) using readline 5.1
 
		Connection id:          9
 
		Current database:
 
		Current user:           root@10.1.1.1
 
		SSL:                    Cipher in use is TLS_CHACHA20_POLY1305_SHA256
 
		Current pager:          /usr/bin/less
 
		Using outfile:          ''
 
		Using delimiter:        ;
 
		Server:                 MariaDB
 
		Server version:         10.4.7-MariaDB-log Source distribution
 
		Protocol version:       10
 
		Connection:             host2.pgnd.lan via TCP/IP
 
		Server characterset:    utf8mb4
 
		Db     characterset:    utf8mb4
 
		Client characterset:    utf8mb4
 
		Conn.  characterset:    utf8mb4
 
		TCP port:               3306
 
		Uptime:                 49 sec
 
		Threads: 8
 
		Questions: 4
 
		Slow queries: 0
 
		Opens: 16
 
		Flush tables: 1
 
		Open tables: 10
 
		Queries per second avg: 0.081
 
		--------------

verifying certs' extended key usage,@host1 's client,

openssl x509 -text -noout -in /srv/ssl/host1/client.EC.crt.pem | grep "Key Usage" -A1
 
	X509v3 Key Usage: critical
 
		Digital Signature, Non Repudiation
 
	X509v3 Extended Key Usage:
 
		TLS Web Client Authentication, E-mail Protection

& @host2 's server,

openssl x509 -text -noout -in  /srv/ssl/host2/server.EC.crt.pem  | grep "Key Usage" -A1
 
	X509v3 Key Usage: critical
 
		Digital Signature
 
	X509v3 Extended Key Usage:
 
		TLS Web Server Authentication



 Comments   
Comment by pgnd [ 2019-07-23 ]

It appears that for

[client]
 
...
 
ssl_verify_server_cert

to work, the server (@host2) certs' "/CN" must contain/match the client (@host1) "-h <hostname>".

@host2's MDB instance listens on an INTERNAL ip address, 'host2.pgnd.lan'.

The certs had only the CN for the external hostname, 'host2.example.com'.

Adding 'host2.pgnd.lan' to the cert's [alt_names] stanza, or generating a unique, matching cert for it, does the trick.

@host1->@host2 connection, WITH 'ssl_verify_server_cert' enabled now works.

Comment by Hartmut Holzgraefe [ 2022-05-10 ]

That is indeed the purpose of the ssl_verify_server_cert option: to verify that the CN in the server certificate, or when the SubjectAlternativeNames (SAN) extension is used: one of the SAN entries, matches the server name as given by the client in the connect call (or connect string).

So "not a bug" I'd say.

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