CentOS Linux release 7.6.1810 (Core)

Name : MariaDB-client
Version : 10.3.12
Release : 1.el7.centos
Architecture: x86_64
Install Date: Wed 09 Jan 2019 11:28:31 AM MST
Group : Applications/Databases
Size : 232971328
License : GPLv2
Signature : DSA/SHA1, Sat 05 Jan 2019 12:50:24 PM MST, Key ID cbcb082a1bb943db
Source RPM : MariaDB-client-10.3.12-1.el7.centos.src.rpm
Build Date : Fri 04 Jan 2019 09:40:53 AM MST
Build Host : centos73-amd64
Relocations : (not relocatable)
Vendor : MariaDB Foundation
URL : http://mariadb.org
Summary : MariaDB: a very fast and robust SQL database server

Name : MariaDB-server
Version : 10.3.12
Release : 1.el7.centos
Architecture: x86_64
Install Date: Wed 09 Jan 2019 11:28:56 AM MST
Group : Applications/Databases
Size : 539357683
License : GPLv2
Signature : DSA/SHA1, Sat 05 Jan 2019 12:50:29 PM MST, Key ID cbcb082a1bb943db
Source RPM : MariaDB-server-10.3.12-1.el7.centos.src.rpm
Build Date : Fri 04 Jan 2019 09:41:54 AM MST
Build Host : centos73-amd64
Relocations : (not relocatable)
Vendor : MariaDB Foundation
URL : http://mariadb.org
Summary : MariaDB: a very fast and robust SQL database server

It appears to be the same as MDEV-18131, or am I missing a difference?

The two could definitely be related, but MDEV-18131 deals specifically with a mixed use case of IP Address & DNS entries in the subject alternate name. (I think SAN names which are not the SAN IP Address entry are validating in MDEV-18131).

Offhand it appears that MariaDB only calls X509_check_host, but MySQL / Percona will additionally call X509_check_ip to validate an ip address. It seems that when there is at least one DNS entry in the subject alt name, the verification fails even if the common name would otherwise match.

In the current (MDEV-18277) issue, neither SAN DNS or IP Address entries are validating. So I'm not sure if they are the same, or have the same cause. I could try a certificate without the IP Address entries and see if that certificate validates. If it does, then it is most likely the same as MDEV-18131.

I can reproduce this issue with MariaDB 10.3.12-2 at Debian 10 (Buster) from Debian's package repository.

Certificate:

    Data:

        Subject: […] CN = public.example.net […]

        X509v3 extensions:

            Netscape Comment: 

                Easy-RSA Generated Server Certificate

            X509v3 Subject Alternative Name: 

                DNS:public.example.net, DNS:internal.example.net

Connection to public.example.net works fine. But it fails with --ssl-verify-server-cert to internal.example.net:

$ mysql -h internal.example.net -u username -ppassword --ssl-ca=ca.pem --ssl-cert=client.pem --ssl-key=client.key --ssl-verify-server-cert

ERROR 2026 (HY000): SSL connection error: SSL certificate validation failure

It looks like the X509_check_host function that includes the SAN in server certificate verification is only called if the HAVE_X509_check_host macro is defined:

https://github.com/MariaDB/server/blob/mariadb-10.3.14/sql-common/client.c#L1834

And it looks like that macro is only defined if the binaries are built on a system that has OpenSSL 1.0.2 or later:

https://github.com/MariaDB/server/blob/mariadb-10.3.14/include/ssl_compat.h#L22

This makes sense, because the function does not seem to be present in OpenSSL 1.0.1 or earlier.

However, we also know that our MariaDB RPMs are built on systems that use OpenSSL 1.0.1 because of MDEV-15848. So even if you are on an RHEL 7 system that has OpenSSL 1.0.2, you are still using the OpenSSL 1.0.1 interface. e.g.:

$ cat /etc/redhat-release

Red Hat Enterprise Linux Server release 7.2 (Maipo)

$ rpm -qa | grep openssl

openssl-devel-1.0.2k-16.el7.x86_64

openssl-libs-1.0.2k-16.el7.x86_64

openssl-1.0.2k-16.el7.x86_64

$ sudo mysql -u root --execute="SHOW GLOBAL VARIABLES LIKE 'version_ssl_library';"

+---------------------+---------------------------------+

| Variable_name       | Value                           |

+---------------------+---------------------------------+

| version_ssl_library | OpenSSL 1.0.1e-fips 11 Feb 2013 |

+---------------------+---------------------------------+

After the changes introduced to fix MDEV-18893, MariaDB RPMs for RHEL/CentOS 7 will be built on systems that use OpenSSL 1.0.2. That should mean that versions starting with 10.2.23, 10.3.14, and 10.4.4 will be built with OpenSSL 1.0.2 on RHEL/CentOS 7. I've confirmed that MariaDB 10.2.23 and MariaDB 10.3.14 on RHEL/CentOS 7 both have the following output:

MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'version_ssl_library';

+---------------------+----------------------------------+

| Variable_name       | Value                            |

+---------------------+----------------------------------+

| version_ssl_library | OpenSSL 1.0.2k-fips  26 Jan 2017 |

+---------------------+----------------------------------+

1 row in set (0.001 sec)

So if anyone is having this issue with server certificate verification with SANs, you might want to see if it works if you update your clients to one of these versions that are built with OpenSSL 1.0.2.

I've confirmed that one user was able to solve this problem on CentOS/RHEL 7 by upgrading to one of the versions with the changes introduced to fix MDEV-18893.

I added the following note to the documentation:

On RHEL and CentOS 7, MariaDB's RPM packages were built with OpenSSL 1.0.1 for a long time, even after OpenSSL 1.0.2 became available on the platform. As a side effect, the clients and utilities bundled in these packages did not support server certificate verification with the subjectAltName field, even if the packages were installed on a system that had OpenSSL 1.0.2 installed. Starting with MariaDB 10.2.23, MariaDB 10.3.14, and MariaDB 10.4.4, MariaDB's RPM packages on RHEL and CentOS 7 are built with OpenSSL 1.0.2. Therefore, these are the minimum required versions to support server certificate verification with the subjectAltName field when using the clients and utilities bundled in MariaDB's RPM packages on RHEL and CentOS 7. See MDEV-18277 for more information.

https://mariadb.com/kb/en/library/secure-connections-overview/#server-certificate-verification

serg,

Should we go ahead and close this? Or is there something else that you think should be done for this?

Let's close it, as seems to work now.

I believe that MariaDB 10.1.39 should also be fixed, since it is also built with OpenSSL 1.0.2:

MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'version_ssl_library';

+---------------------+----------------------------------+

| Variable_name       | Value                            |

+---------------------+----------------------------------+

| version_ssl_library | OpenSSL 1.0.2k-fips  26 Jan 2017 |

+---------------------+----------------------------------+

1 row in set (0.00 sec)

MariaDB [(none)]> SELECT VERSION();

+-----------------+

| VERSION()       |

+-----------------+

| 10.1.39-MariaDB |

+-----------------+

1 row in set (0.00 sec)

And 10.1.39 also contains the relevant compile-time checks:

https://github.com/MariaDB/server/blob/mariadb-10.1.39/sql-common/client.c#L1840

https://github.com/MariaDB/server/blob/mariadb-10.1.39/sql-common/client.c#L1790