We are currently using the encrypted database connectionas described in Bug 36026 with Koha 24.11.12 under Debian 11 with no issue When updating to Debian 12 the connection breaks with the error message: DBIx::Class::Storage::DBI::catch {...} (): DBI Connection failed: DBI connect('database=koha_instance;host=ourdbhost.de;port=3306;mysql_ssl=1;mysql_ssl_ca_file=/etc/ssl/certs/harica-ca.pem','koha_kohat',...) failed: SSL connection error: Enforcing SSL encryption is not supported at /usr/share/koha/lib/Koha/Database.pm line 75. at /usr/share/koha/lib/Koha/Database.pm line 123 Some additional information: - Database version: 11.8.3-MariaDB-deb12-log (on separate database server, unchanged by update) - DBD::mysql (4.004 ) 4.050 - DB connection can be established through koha-mysql and mysql/mariadb commands We’ve found a workaround editing Database.pm and adding the mysql_ssl_optional option: if ( $driver eq 'mysql' ) { $attr->{mysql_enable_utf8} = 1; + $attr->{mysql_ssl_optional} = 1; } At the same time enforcing encryption through the database user with: ALTER USER ... REQUIRE SSL; We assume that the problem is in DBD::mysql and is related to the way DBD::mysql (or Koha?) is enforcing SSL on the client side. As the workaround shows, DBD::mysql is still able to start a secure connection if it's not enforced that way. ** Related Debian bug report: https://bugs-devel.debian.org/cgi-bin/bugreport.cgi?bug=1032074 ** $ perl -MDBD::mysql -e 'print "DBD::mysql=", $DBD::mysql::VERSION, "\n"' DBD::mysql=4.050 $ dpkg -l | egrep 'libdbd-mysql-perl|libmariadb|libmysqlclient' ii libdbd-mysql-perl:amd64 4.050-5+b1 amd64 Perl5 database interface to the MariaDB/MySQL database ii libmariadb3:amd64 1:10.11.14-0+deb12u2 amd64 MariaDB database client library We changed nothing on the database server side during the upgrade of the Koha server from Debian 11 to Debian 12. The database server is on Debian 13 already and everything worked well with Koha 24.11 on Debian 11 but it stopped working with Debian 12. Documentation of DBD::mysql suggests this might not be the ideal solution: https://metacpan.org/pod/DBD::mysql 'Setting mysql_ssl_optional to true disables strict SSL enforcement and makes SSL connection optional. This option opens security hole for man-in-the-middle attacks. Default value is false which means that mysql_ssl set to true enforce SSL encryption. This option was introduced in 4.043 version of DBD::mysql. Due to The BACKRONYM and The Riddle vulnerabilities in libmysqlclient library, enforcement of SSL encryption was not possbile and therefore mysql_ssl_optional=1 was effectively set for all DBD::mysql versions prior to 4.043. Starting with 4.043, DBD::mysql with mysql_ssl=1 could refuse connection to MySQL server if underlaying libmysqlclient library is vulnerable. Option mysql_ssl_optional can be used to make SSL connection vulnerable.'
Hmm interesting. According to https://github.com/perl5-dbi/DBD-mysql/issues/351 it should be fixed in DBD::mysql at some point (based off the timing of the comment and releases... maybe 4.0.51 which is Debian 13. Looking at patches for the 4.0.50 in Debian 12 and I don't see anything obvious for SSL) On that same issue report, someone said they fixed it by switching to DBD::MariaDB. Looking at the code for DBD::mysql... I can see the error message comes from dbdimp.c Aha... in 4.0.50 there is this line which unsets "ssl_mode": (defined(CLIENT_SSL) || (MYSQL_VERSION_ID >= 40000)) char *client_key = NULL; char *client_cert = NULL; char *ca_file = NULL; char *ca_path = NULL; char *cipher = NULL; STRLEN lna; unsigned int ssl_mode; That block isn't in the master branch, but it's in every 4.x release. It looks like it was removed in 5.x. And if we look at the changelog... I think that's probably covered by "Only support MySQL 8.x as MySQL 5.7 is going EOL soon" so he took out the hack that unset ssl_mode. Well that's a big pain in the butt... since the version included in every version of Debian and Ubuntu is 4.x. He created 5.x in 2023 but has continued updating 4.x in 2025. But then... the version of libdbd-mysql-perl is very similar between Debian 11 and Debian 12 at a glance...
Ah wait I think I was mixing up some variable names... If mysql_ssl is set, ssl_enforce should be 1... But ssl_mode is what is attempted to set the ssl mode... Yeah nah... the DBD::mysql code looks like it should be attempting to set the SSL... which is probably why there is the message "Enforcing SSL encryption is not supported" I guess...which suggests the C library is the problem... It does seem that you're using libmariadb for the client library rather than libmysql and this is sounding familiar... which is probably why Katrin added me to the CC...
Back in August 2025 I was getting this error trying to start KTD which was using the mysql CLI I think: ERROR 2026 (HY000): TLS/SSL error: SSL is required, but the server does not support it I ended up turning off SSL to get the KTD to startup...
Reading through that Debian bug 1032074 and that leads to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024241 which... yeah yikes... It seems like a total mess. Not sure I follow the argument used in 1032074 for what the problem is but I don't know what the compile time macros were set to...it seems unlikely ssl_verify_also_enforce_ssl would run and yet... the error we see seems likely the product of that function combined with the bug in libmariadb: https://github.com/mariadb-corporation/mariadb-connector-c/commit/a37b7c3965706f9a062baaba0c494dd6efb2c306
Ok I misread 1032074 but now I get it. If you look at dbdimp.h you can see that every SSL macro won't be set because the version number returned by the bad MariaDB client library will be wrong. So we fall through to: #else set_ssl_error(sock, "Enforcing SSL encryption is not supported"); return NULL; #endif Setting mysql_ssl_optional would work because it would turn off ssl_enforce. -- Yeah... I think you are stuck here unless MariaDB change their connector: https://github.com/mariadb-corporation/mariadb-connector-c/pull/219 An alternative would be to switch to using the MySQL client library instead of the MariaDB one. In KTD it looks like we're using MariaDB client but I use the MySQL client myself. -- Definitely a bit of a mess...
Thanks David, I have to admit that I didn't remember the problem you had mentioned earlier, but this kind of "mess" seemed like something you might have an idea about. Many thanks for digging into it and sharing your thoughts! Is there anything we can currently do to help get this fixed?
Hi David, thanks for your analysis! You wrote that we could maybe switch from mariadb client library to the mysql client library. How could this be done? I think Koha uses DBD:mysql and not MariaDB?
(In reply to Katrin Fischer from comment #6) > Thanks David, I have to admit that I didn't remember the problem you had > mentioned earlier, but this kind of "mess" seemed like something you might > have an idea about. Many thanks for digging into it and sharing your > thoughts! Haha. You know me... I'm a sucker for these kinds of problems. > Is there anything we can currently do to help get this fixed? Mmm I'm not sure. I'm discussing it at https://github.com/perl5-dbi/DBD-mysql/issues/351 with the DBD::mysql author. You could confirm that you're using the MariaDB client version 1:10.11.14-0+deb12u2 I think that I've found the proof for the theory that people put on the Debian tickets, so hopefully the DBD::mysql can help. -- Basically, the MariaDB client is returning the wrong version number when DBD::mysql calls mysql_get_client_version() as defined in mysql.h. Looking at /usr/include/mariadb/mariadb_version.h you can see that MARIADB_PACKAGE_VERSION_ID is 30317 and that's what's used for mysql_get_client_version in the MariaDB connector: https://github.com/mariadb-corporation/mariadb-connector-c/blob/3.4/libmariadb/mariadb_lib.c#L4532 Whomp whomp...
(In reply to Cornelius Hertfelder from comment #7) > Hi David, > thanks for your analysis! You wrote that we could maybe switch from mariadb > client library to the mysql client library. How could this be done? I think > Koha uses DBD:mysql and not MariaDB? So Koha uses DBD::mysql but the MariaDB client library is interchangeable with the MySQL client library. So I referenced mysql.h before... that file is used for both MySQL and MariaDB. Looking again... I realise that I was thinking of Ubuntu rather than Debian. Ubuntu comes with both but Debian only has the MariaDB client library. It looks like Debian "sid" has added mysql-client back in but stable versions don't have it. You'd have to look at sourcing it (and its dependencies) from elsewhere. For instance, you can do "wget https://dev.mysql.com/get/mysql-apt-config_0.8.36-1_all.deb", apt install that, and then you have an interactive configuration of an apt repo source. After that, you can run the following: apt-get remove mariadb-client apt-get remove mariadb-client-core apt-get install mysql-client Now I'm not recommending this per se... but it's how you *could* do it.
Hi David, we are using dpkg -l | grep libmariadb ii libmariadb3:amd64 1:10.11.14-0+deb12u2 amd64 MariaDB database client library there is no related mysql library. But dpkg -l | grep libdbd ii libdbd-mysql-perl:amd64 4.050-5+b1 amd64 Perl5 database interface to the MariaDB/MySQL database ii libdbd-pg-perl 3.16.0-2 amd64 Perl DBI driver for the PostgreSQL database server ii libdbd-sqlite3-perl:amd64 1.72-1 amd64 Perl DBI driver with a self-contained RDBMS Not sure if this points us to mariadb or mysql. /usr/bin/mysql is a symlink to mariadb. But the command line client does not have this problem, it's the perl client. Hope that helps! Installing a foreign package source on a production system might break later and then we will need days investigating whats going wrong. Maybe a upgraded version can be installed via backports in future, that would be my preferred solution.
Hi Cornelius, Yes, as I noted previously, Debian only has the MariaDB client. As you say, there would be risk installing directly from MySQL. Fortunately, I've managed to assist the DBD::mysql author in troubleshooting this, and he's written a Perl-based fix. It's not on MetaCPAN yet, but when adds it... then there's options. Once it's up there, I can reply on the Debian bugs and see if they'll backport it. If they don't... either you or the Koha community could try to roll their own libdbd-mysql-perl but since it uses C libraries that would need to be done for every supported OS. Not fun. Not impossible but not fun. -- Btw, the problem isn't with DBD::mysql. Rather, the problem is with libmariadb3. The author of DBD::mysql is willing to code a workaround so that libmariadb3 will still work, but MariaDB is the problem - not the Perl library.