Encryption in transit secures data exchanged between MariaDB clients and the server by wrapping every packet in SSL/TLS.
Encryption in transit protects data on the wire by forcing MariaDB to use SSL/TLS for every client-server packet, eliminating plaintext snooping risks.
Run SHOW VARIABLES LIKE 'have_ssl';
. If it returns YES
, the server has SSL libraries. A value of DISABLED
or NO
means you must recompile or install the SSL plugin.
Add ssl-ca
, ssl-cert
, and ssl-key
paths under the [mysqld]
section of my.cnf
. Restart the instance to activate TLS handshakes.
Use REQUIRE SSL
in CREATE USER
or ALTER USER
. Clients that fail the TLS negotiation cannot connect.
Query SELECT ssl_version, ssl_cipher FROM information_schema.processlist WHERE id = CONNECTION_ID();
. A non-NULL result confirms an encrypted link.
Pass connection parameters such as --ssl-ca
, --ssl-cert
, and --ssl-key
(CLI) or their driver-specific equivalents (useSSL=true
, requireSSL=true
in JDBC).
Expect a 2-5 % CPU overhead during handshakes and encryption. Modern CPUs with AES-NI typically hide the cost in normal workloads.
Rotate certificates yearly, prefer TLS v1.2+, disable weak ciphers, and automate certificate distribution with tools such as Vault or cert-manager.
1) Certificates issued by trusted CA 2) Strong DH parameters 3) Firewall rules allow 3306 only over TLS 4) Monitoring alerts on have_ssl
and expired certs.
Use self-signed only for internal testing. Production should rely on a trusted internal or public CA to avoid MITM risks.
Yes. Accounts without REQUIRE SSL
can still connect unencrypted, but doing so creates compliance gaps. Prefer full enforcement.
Absolutely. Configure CHANGE MASTER TO MASTER_SSL=1
and provide certificates to protect binlog streams.