When MariaDB Server is compiled with TLS and cryptography support, it is usually either statically linked with MariaDB's bundled TLS and cryptography library or dynamically linked with the system's OpenSSL library. MariaDB's bundled TLS library is either wolfSSL or yaSSL, depending on the server version.
When a MariaDB client or client library is compiled with TLS and cryptography support, it is usually either statically linked with MariaDB's bundled TLS and cryptography library or dynamically linked with the system's TLS and cryptography library, which might be OpenSSL, GnuTLS, or Schannel.
Dynamically linking MariaDB to the system's TLS and cryptography library can often be beneficial, since this allows you to fix bugs in the system's TLS and cryptography library independently of MariaDB. For example, when information on the in was released in 2014, the bug could be mitigated by simply updating your system to use a fixed version of the library, and then restarting the MariaDB Server.
You can verify that mysqld is in fact dynamically linked to the shared library on your system by using the command:
If the command does not return any results, then either your mysqld is statically linked to the TLS and cryptography library on your system or your mysqld is not built with TLS and cryptography support at all.
If you aren't sure whether your server is linked with or the bundled TLS library, then you can check the value of the system variable. For example:
If you want to see what version of your server is using, then you can check the value of the system variable. For example:
Note that the version returned by this system variable does not always necessarily correspond to the exact version of the package installed on the system. shared libraries tend to contain interfaces for multiple versions at once to allow for backward compatibility. Therefore, if the package installed on the system is newer than the version that the MariaDB Server binary was built with, then the MariaDB Server binary might use one of the interfaces for an older version. See for more information. For example:
are standards published by the U.S. federal government that are used to establish requirements for various aspects of computer systems. is a set of standards for security requirements for cryptographic modules.
This standard is relevant when discussing the TLS and cryptography libraries used by MariaDB. Some of these libraries have been certified to meet the standards set by FIPS 140-2.
The library has a special FIPS mode that has been certified to meet the FIPS 140-2 standard. In FIPS mode, only algorithms and key sizes that meet the FIPS 140-2 standard are enabled by the library.
MariaDB does not yet support enabling FIPS mode within the database server. See for more information. Therefore, if you would like to use OpenSSL's FIPS mode with MariaDB, then you would either need to enable FIPS mode at the kernel level or enable it via the OpenSSL configuration file, system-wide or only for the MariaDB process.. See the following resources for more information on how to do that:
The standard version of the library has not been certified to meet the FIPS 140-2 standard, but a special version has been certified. Unfortunately, the "FIPS-ready" version of wolfSSL uses a license that is incompatible with MariaDB's license, so it cannot be used with MariaDB.
The library has not been certified to meet the FIPS 140-2 standard.
MariaDB Server is statically linked with the bundled library in and packages on Windows.
MariaDB Server in Binary Tarballs
MariaDB Server is statically linked with the bundled library in on Linux.
MariaDB Server in DEB Packages
MariaDB Server is dynamically linked with the system's library in packages.
See for more information.
MariaDB Server in RPM Packages
MariaDB Server is dynamically linked with the system's library in packages.
has been included with MariaDB Server, and the bundled and the clients and utilities are linked with it. On some platforms, and these may use a different TLS library than the one used by MariaDB Server and .
MariaDB's and are dynamically linked with the system's libraries in and packages on Windows. is still statically linked with the bundled library. <>
MariaDB Clients and Utilities in Binary Tarballs
MariaDB's and are statically linked with the library in on Linux. is still statically linked with the bundled library. <>
MariaDB Clients and Utilities in DEB Packages
MariaDB's , , and are dynamically linked with the system's library in packages.
See for more information.
MariaDB Clients and Utilities in RPM Packages
MariaDB's , , and are dynamically linked with the system's library in packages.
When the MariaDB Server or clients and utilities are dynamically linked to the system's library, it makes it very easy to update the libraries. The information below will show how to update these libraries for each platform.
On RHEL, CentOS, Fedora, and other similar Linux distributions, it is highly recommended to update the libraries using or . Starting with RHEL 8 and Fedora 22, yum has been replaced by dnf, which is the next major version of yum. However, yum commands still work on many systems that use dnf. For example:
Update the package by executing the following command:
And then restart MariaDB server and any clients or applications that use the library.
On Debian, Ubuntu, and other similar Linux distributions, it is highly recommended to recommended to update the libraries using . For example:
First update the package cache by executing the following command:
And then update the package by executing the following command:
And then MariaDB server and any clients or applications that use the library.
On SLES, OpenSUSE, and other similar Linux distributions, it is highly recommended to recommended to update the libraries using . For example:
Update the package by executing the following command:
And then MariaDB server and any clients or applications that use the library.
This page is licensed: CC BY-SA / Gnu FDL
$ ldd $(which mysqld) | grep -E '(libssl|libcrypto)'
libssl.so.10 => /lib64/libssl.so.10 (0x00007f8736386000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f8735f25000)SHOW GLOBAL VARIABLES LIKE 'have_openssl';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| have_openssl | YES |
+---------------+-------+SHOW GLOBAL VARIABLES LIKE 'version_ssl_library';
+---------------------+---------------------------------+
| Variable_name | Value |
+---------------------+---------------------------------+
| version_ssl_library | OpenSSL 1.0.1e-fips 11 Feb 2013 |
+---------------------+---------------------------------+$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.5 (Maipo)
$ rpm -q openssl
openssl-1.0.2k-12.el7.x86_64
$ mysql -u root --batch --execute="SHOW GLOBAL VARIABLES LIKE 'version_ssl_library';"
Variable_name Value
version_ssl_library OpenSSL 1.0.1e-fips 11 Feb 2013
$ ldd $(which mysqld) | grep libcrypto
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f3dd3482000)
$ readelf -a /lib64/libcrypto.so.10 | grep SSLeay_version
1374: 000000000006f5d0 21 FUNC GLOBAL DEFAULT 13 SSLeay_version@libcrypto.so.10
1375: 000000000006f5f0 21 FUNC GLOBAL DEFAULT 13 SSLeay_version@OPENSSL_1.0.1
1377: 000000000006f580 70 FUNC GLOBAL DEFAULT 13 SSLeay_version@@OPENSSL_1.0.2sudo yum update opensslsudo apt updatesudo apt-get update opensslsudo zypper update openssl