To enforce encryption in MySQL, set require_secure_transport=ON on the server so it rejects unencrypted TCP connections. To make sure clients talk to the real server, set their ssl-mode to VERIFY_IDENTITY, or VERIFY_CA at minimum. The server setting and the client setting protect against different things.
What the server setting does
The MySQL manual says that with require_secure_transport enabled, clients must use some form of secure transport. The server permits only TCP/IP connections that use SSL, or connections over a Unix socket file or shared memory. Insecure attempts are rejected with an ER_SECURE_TRANSPORT_REQUIRED error.
[mysqld]
require_secure_transport=ON
At runtime, SET PERSIST require_secure_transport=ON; keeps the change across restarts. Test in staging first, because any client still connecting without TLS will begin to fail.
Per account requirements
You can also require encryption for specific accounts with a REQUIRE clause on CREATE USER or ALTER USER. The manual shows REQUIRE X509 for certificate based login, and REQUIRE SSL is another valid form. This is useful when you cannot flip the whole server at once and want to start with the accounts that matter most, such as administrators and anything used from outside your network.
Client ssl-mode values
The manual lists these client modes:
| Mode | Behavior |
|---|---|
| PREFERRED (default) | Tries encryption, falls back to unencrypted |
| REQUIRED | Fails if encryption cannot be established |
| DISABLED | No encryption |
| VERIFY_CA | Encrypted, and verifies the server certificate against the CA |
| VERIFY_IDENTITY | As VERIFY_CA, and checks the host name matches the certificate |
The default is the weak one. It encrypts when it can and silently continues without it, so a network attacker who blocks the TLS handshake wins. The manual recommends VERIFY_CA or VERIFY_IDENTITY to protect against man in the middle attacks.
Why identity matters
Encryption without verification protects against someone reading traffic, but not against someone pretending to be your database. VERIFY_IDENTITY makes the client check that the host name it dialed matches the server certificate. The manual notes this does not work with server generated self signed certificates because they lack the server name as the common name. Issue a certificate from a CA your clients trust, and distribute the CA certificate to them.
The same logic applies in PostgreSQL, where require and verify-full split the same way. See PostgreSQL sslmode compared.
Rollout order
- Inventory clients and their connection options.
- Install a proper server certificate and distribute the CA certificate.
- Move clients to
VERIFY_IDENTITY, one service at a time. - Turn on
require_secure_transportonce nothing connects in the clear. - Use
tls_versionto prevent clients from using less secure protocols. The manual points to its TLS protocols section for defaults, so read that for your version.
Quick check
Does require_secure_transport verify the server certificate?
No. It makes the server refuse unencrypted TCP connections. Certificate checking happens on the client through ssl-mode VERIFY_CA or VERIFY_IDENTITY.
Are local socket connections affected?
The manual says Unix socket and shared memory connections are still permitted when the setting is on.
Sources
Last reviewed: 19 October 2026.
