Bug#892514: libdbd-mysql-perl: 4.046-1 SSL certificate validation failure

[Corey Hickey]

Package: libdbd-mysql-perl
Version: 4.046-1
Severity: normal

Dear Maintainer,

Upon upgrade from 4.041-2+b1 to 4.046-1, I can no longer connect to our
mysql database with SSL. Reverting to 4.041-2+b1 makes the connection
work again.

Here is a test script to reproduce (with database name and hostname set
to example values).
-----------------------------------------------------------------------
#!/usr/bin/perl
use DBI;
my $dsn = 'DBI:mysql:database=exampledb;host=example.com;mysql_ssl=1;mysql_ssl_ca_file=/tmp/ca_cert.pem';
my $conn = DBI->connect($dsn, 'foo', 'foo');
-----------------------------------------------------------------------



Outputs from the versions follow, with internal
information replaced with '<cut>'.

On 4.041-2+b1:
-----------------------------------------------------------------------
DBI connect('database=<cut>;host=<cut>;mysql_ssl=1;mysql_ssl_ca_file=/tmp/ca_cert.pem','foo',...) failed: Access denied for user 'foo'@'<cut>' (using password: YES) at /tmp/test.pl line 4.
-----------------------------------------------------------------------
(access denied is ok--it got past the SSL part)


On 4.046-1:
-----------------------------------------------------------------------
DBI connect('database=<cut>;host=<cut>;mysql_ssl=1;mysql_ssl_ca_file=/tmp/ca_cert.pem','foo',...) failed: SSL connection error: SSL certificate validation failure at /tmp/test.pl line 4.
-----------------------------------------------------------------------
(this one fails)


I have verified the following:
1. That the old version is indeed using SSL, via wireshark.
2. That both old and new versions are reading /tmp/ca_cert.pem, via
strace.
3. That the server certificate has not expired, that it contains the
target servername (as an X509v3 SAN), and that it verifies OK
against the CA cert, via openssl.


I can imagine two possiblities; either:
a. Version 4.046-1 is more strict about validation and something is
actually wrong, but I can't tell what.
b. There is a regression in validation in 4.046-1.

Either way, it worked before and does not now, so that seems worth
filing a bug over, to start with.

Thanks for your support,
Corey


-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libdbd-mysql-perl depends on:
ii libc6 2.27-1
ii libdbi-perl [perl-dbdabi-94] 1.640-1
ii libmariadbclient18 1:10.1.29-6
ii perl 5.26.1-5
ii perl-base [perlapi-5.26.1] 5.26.1-5
ii zlib1g 1:1.2.8.dfsg-5

libdbd-mysql-perl recommends no packages.

libdbd-mysql-perl suggests no packages.

-- no debconf information

[Corey Hickey]

The problem in more detail is that when the server hostname is listed as
a SubjectAltName ("SAN") in the certificate, then validation fails.
Validation only succeeds if the server hostname is in the CN of the
certificate.

This seems likely to be a bug in the underlying mariadb library. I was
unable to find an exact bug report for this, but I did find two similar
ones:

Bug for mysql, not mariadb:
https://bugs.mysql.com/bug.php?id=68052

Supposedly fixed in mariadb 10.1.23, but I am seeing problems in 10.1.29:
https://jira.mariadb.org/browse/MDEV-10594

I was able to reproduce the problem with the command-line mysql client
as provided by mariadb-client-core-10.1:

$ mysql exampledb -h example.com --ssl-verify-server-cert=true --ssl \
--ssl-ca /tmp/ca_cert.pem
ERROR 2026 (HY000): SSL connection error: SSL certificate validation failure


This problem goes away when I upgrade to mariadb-client-core-10.3 from
experimental. Unfortunately, I was unable to do that for
libdbd-mysql-perl, since that requires libmariadbclient18, which is
apparently not provided for mariadb 10.3 in experimental.


$ ldd /usr/lib/x86_64-linux-gnu/perl5/5.26/auto/DBD/mysql/mysql.so
linux-vdso.so.1 (0x00007ffd9e9f7000)
libmariadbclient.so.18 => /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 (0x00007f6bb6452000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6bb6431000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f6bb6213000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6bb607f000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6bb607a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6bb5ebd000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6bb5d38000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6bb6c7b000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6bb5d1e000)


Thanks,
Corey

[Corey Hickey]

I filed a bug against mariadb-client-core-10.1 for this:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904223

I don't know if there is anything that can be done for
libdbd-mysql-perl, since the problem seems to be in the underlying
mariadb library.

-Corey