Prior to MariaDB 11.4, by default, MariaDB transmits data between the server and clients without encrypting it. This is generally acceptable when the server and client run on the same host or in networks where security is guaranteed through other means. However, in cases where the server and client exist on separate networks or they are in a high-risk network, the lack of encryption does introduce security concerns as a malicious actor could potentially eavesdrop on the traffic as it is sent over the network between them.
To mitigate this concern, MariaDB allows you to encrypt data in transit between the server and clients using the Transport Layer Security (TLS) protocol. TLS was formerly known as Secure Socket Layer (SSL), but strictly speaking the SSL protocol is a predecessor to TLS and, that version of the protocol is now considered insecure. The documentation still uses the term SSL often and for compatibility reasons TLS-related server system and status variables still use the prefix ssl_, but internally, MariaDB only supports its secure successors.
In order for MariaDB Server to use TLS, it needs to be compiled with TLS support. All MariaDB packages distributed by MariaDB Foundation and MariaDB Corporation are compiled with TLS support.
If you aren't sure whether your MariaDB Server binary was compiled with TLS support, then you can check the value of the system variable. For example:
The possible values are:
If it is DISABLED, then the server was compiled with TLS support, but TLS is not enabled.
If it is YES, then the server was compiled with TLS support, and TLS is enabled.
If it is NO, then the server was not compiled with TLS support.
When MariaDB is compiled with TLS and cryptography support, it is usually either statically linked with MariaDB's bundled TLS and cryptography library, which might be or , or dynamically linked with the system's TLS and cryptography library, which might be , , or .
See for more information about which libraries are used on which platforms.
There are 4 versions of the TLS protocol:
TLSv1.0
TLSv1.1
TLSv1.2
TLSv1.3
In some cases, it might make sense to only enable specific TLS protocol versions. For example, it would make sense if your organization has to comply with a specific security standard. It would also make sense if a vulnerability is found in a specific TLS protocol version, and you would like to ensure that your server does not use the vulnerable protocol version.
The recommends using a minimum protocol version of TLSv1.2.
On the server side, users can enable specific TLS protocol versions by setting the system variable. This system variable accepts a comma-separated list of TLS protocol versions. A TLS protocol version will only be enabled if it is present in this list. All other TLS protocol versions will not be permitted. This system variable can be specified as a command-line argument to or it can be specified in a relevant server in an . For example:
You can check which TLS protocol versions are enabled on a server by executing . For example:
On the client side, users can enable specific TLS protocol versions by setting the --tls-version option. This option accepts a comma-separated list of TLS protocol versions. A TLS protocol version will only be enabled if it is present in this list. All other TLS protocol versions will not be permitted. For example, to specify this option in a relevant client in an , you could set the following:
Or if you wanted to specify it on the command-line with the client, then you could execute something like this:
The TLS protocol versions that are supported depend on the underlying TLS library used by the specific MariaDB binary.
See for more information about which libraries are used by the server and by clients on each platform.
MariaDB binaries built with the library ( or later) support TLSv1.1 and TLSv1.2 since , , and .
MariaDB binaries built with the library ( or later) support TLSv1.3 since and .
If your MariaDB Server binary is built with , then you can set the system variable to values like SSLv3 or TLSv1.2 to allow all SSLv3.0 or all TLSv1.2 ciphers. However, this does not necessarily limit the protocol version to TLSv1.2. See for more information about that.
Note that the TLSv1.3 ciphers cannot be excluded when using , even by using the system variable. See for details.
SSLv3.0 is known to be vulnerable to the , so it should not be used. SSLv2.0 and SSLv3.0 are disabled for MariaDB Server binaries linked with since , , and . If you are using a MariaDB version older than that and you cannot upgrade, then please see the section titled "SSL 3.0 Fallback protection" in .
MariaDB binaries built with the bundled library support TLSv1.0, TLSv1.1, TLSv1.2, and TLSv1.3.
MariaDB binaries built with the bundled library support SSLv3.0, TLSv1.0, and TLSv1.1.
SSLv3.0 is known to be vulnerable to the , so it should not be used. SSLv2.0 and SSLv3.0 are disabled for MariaDB Server binaries linked with since , , and .
MariaDB binaries built with the library support different versions of TLS on different versions of Windows. See the documentation from Microsoft to determine which versions of TLS are supported on each version of Windows.
MariaDB binaries built with the library support TLSv1.0, TLSv1.1, TLSv1.2, and TLSv1.3.
See for information on how to enable TLS on the client and server.
Certificate verification is how TLS authenticates its connections by verifying that it is talking to who it says it is. There are multiple components to this verification process:
Was the certificate signed by a trusted Certificate Authority (CA)?
Is the certificate expired?
Is the certificate on my Certificate Revocation List (CRL)?
Does the certificate belong to who I believe that I'm communicating with?
Certificate Authorities (CAs) are entities that you trust to sign TLS certificates. Your organization might have its own internal CA, or it might use trusted third-party CAs.
CAs are specified on the server and client by using the and options.
The option defines a path to a PEM file that should contain one or more X509 certificates for trusted Certificate Authorities (CAs). This option requires that you use the absolute path, not a relative path.
The option defines a path to a directory that contains one or more PEM files that should each contain one X509 certificate for a trusted Certificate Authority (CA). This option requires that you use the absolute path, not a relative path. The option is only supported if the server or client was built with , , or . If the client was built with or , then the option is not supported.
See for more information about which libraries are used on which platforms.
The directory specified by needs to be run through the command. For example, if the following is configured:
Then you would have to execute the following:
The server can require a specific Certificate Authority (CA) for a client if the client's user account has been defined with REQUIRE ISSUER. See for more information.
Certificate Revocation Lists (CRLs) are lists of certificates that have been revoked by the Certificate Authority (CA) before they were due to expire.
CRLs are specified on the server and client by using the and options.
The option defines a path to a PEM file that should contain one or more X509 revoked certificates. This option requires that you use the absolute path, not a relative path. For servers, the option is only valid if the server was built with OpenSSL. If the server was built with or , then the option is not supported. For clients, the option is only valid if the client was built with or . Likewise, if the client was built with , or , then the option is not supported.
The option defines a path to a directory that contains one or more PEM files that should each contain one revoked X509 certificate. This option requires that you use the absolute path, not a relative path. The option is only supported if the server or client was built with . If the server was built with or , then the option is not supported. Likewise, if the client was built with , , , or , then the option is not supported.
See for more information about which libraries are used on which platforms.
The directory specified by needs to be run through the command. For example, if the following is configured:
Then you would have to execute the following:
Normally the TLS implementation performs numerous checks to verify whether the certificate is valid. It should be within its validity period, not revoked, signed by a trusted certificate authority, belong to the host that uses it.
enable all these checks by default. Last two checks can be disabled with an option, such as disable-ssl-verify-server-cert. Before , all server certificate verification checks were disabled by default, and could be enabled with the ssl-verify-server-cert option.
To verify whether the server's certificate belong to server's host, will check the Common Name (CN) attribute located in the field of the certificate against the server's host name and IP address. If the Common Name (CN) matches either of those, then the certificate is verified.
The field, which is an X.509v3 extension, can also be used for server certificate verification, if it is present in the server certificate. This field is also sometimes called subjectAltName. When using a that supports server certificate verification with subjectAltName fields, if the server certificate contains any subjectAltName fields, then those fields will also be checked against the server's host name and IP address.
Whether server certificate verification with subjectAltName fields is supported depends on the underlying TLS library used by the .
See for more information about which libraries are used on which platforms.
SAN Support with OpenSSL, wolfSSL, and yaSSL
For built with ( or later), support for server certificate verification with subjectAltName fields that contain the server's host name was added in and . See for more information.
For built with ( or later), support for server certificate verification with subjectAltName fields that contain the server's IP address was added in , , , and . See for more information.
This support also applies to other TLS libraries that use OpenSSL's API. In OpenSSL's API, server certificate verification with subjectAltName fields depends on the and functions. These functions are supported in the following TLS libraries:
1.0.2 or later
And they are not supported in the following TLS libraries:
MariaDB's were built with 1.0.1 on RHEL 7 and CentOS 7, even after OpenSSL 1.0.2 became available on those distributions. As a side effect, the 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 , , , and , MariaDB's on RHEL 7 and CentOS 7 are built with OpenSSL 1.0.2. See for more information.
SAN Support with Schannel
For linked with , support for server certificate verification with subjectAltName fields was added in 3.0.2. See for more information.
SAN Support with GnuTLS
For linked with GnuTLS, support for server certificate verification with subjectAltName fields was added in 3.0.0. See for more information.
The server verifies a client certificate by checking the client's known SUBJECT against the Subject attribute in the client's certificate. This is only done for user accounts that have been defined with REQUIRE SUBJECT. See for more information.
(mariadb.org)
This page is licensed: CC BY-SA / Gnu FDL
openSSL
TLSv1, TLSv1.1, TLSv1.2, TLSv1.3
wolfSSL
TLSv1, TLSv1.1, TLSv1.2, TLSv1.3
yaSSL
TLSv1, TLSv1.1
Schannel
TLSv1, TLSv1.1, TLSv1.2
GnuTLS
TLSv1, TLSv1.1, TLSv1.2, TLSv1.3
SHOW GLOBAL VARIABLES LIKE 'have_ssl';
+---------------+----------+
| Variable_name | Value |
+---------------+----------+
| have_ssl | DISABLED |
+---------------+----------+[mariadb]
...
tls_version = TLSv1.2,TLSv1.3SHOW GLOBAL VARIABLES LIKE 'tls_version';[client-mariadb]
...
tls_version = TLSv1.2,TLSv1.3$ mariadb -u myuser -p -h myserver.mydomain.com \
--ssl \
--tls-version="TLSv1.2,TLSv1.3"ssl_capath=/etc/my.cnf.d/certificates/ca/openssl rehash /etc/my.cnf.d/certificates/ca/ssl_crlpath=/etc/my.cnf.d/certificates/crl/openssl rehash /etc/my.cnf.d/certificates/crl/