A Complete Guide to Securely Connecting TiDB and MySQL Client Using Mutual TLS
How to use TLS, client authentication, and CA certificates in TiDB and MySQL Client
Create a private key and request a certificate for your TiDB server
Before you can teach your server to speak TLS, you will need a certificate issued by a trusted certificate authority (CA). If your organization already runs its own CA and you have a private key and certificate for your TiDB server, along with your CA's root certificate, you can skip to the next step.
To request a certificate from your CA using the step CLI, bootstrap your CA with step ca bootstrap and run the following command (sub the server name for the actual name / DNS name of your TiDB server).
$ step ca certificate "myserver.internal.net" server.crt server.keyYour certificate and private key will be saved in server.crt and server.key respectively.
Request a copy of your CA root certificate, which will be used to make sure each application can trust certificates presented by other applications.
$ step ca root ca.crtYour certificate will be saved in ca.crt.
Configure TiDB to authenticate itself with its TLS certificate
We now want to instruct our TiDB server to identify itself using the certificate issued in the last step and to force clients to connect over TLS.
Copy the server.crt, server.key, and ca.crt files to the directory that contains your TiDB config file.
$ sudo cp server.crt /<tidb-config-dir>/server-cert.pem
$ sudo cp server.key /<tidb-config-dir>/server-key.pem
$ sudo cp ca.crt /<tidb-config-dir>/ca.pemThese files should be owned by the user that runs TiDB. Now add the following to your TiDB config file:
#...
[security]
# Path of file that contains list of trusted SSL CAs for connection with mysql client.
ssl-ca = "ca.pem"
# Path of file that contains X509 certificate in PEM format for connection with mysql client.
ssl-cert = "server-cert.pem"
# Path of file that contains X509 key in PEM format for connection with mysql client.
ssl-key = "server-key.pem"
require-secure-transport=true
#...Restart your TiDB server for these changes to take effect.
Configure TiDB to require clients to authenticate with a certificate issued by your CA
To tell TiDB to use mutual TLS and not just one-way TLS, we must instruct it to require client authentication to ensure clients present a certificate from our CA when they connect.
TiDB requires client certificates to be configured on a per-user basis. The requirement can be configured using CREATE USER or ALTER USER statements. When set, TiDB will reject connections from these users if they don't present a valid certificate signed by your CA.
mysql> CREATE USER 'myuser'@'%' REQUIRE SUBJECT 'CN=myuser';
mysql> ALTER USER 'myuser'@'%' REQUIRE SUBJECT 'CN=myuser';You can require other user certificate information in order to establish a connection.
That's it! TiDB should now be able to receive TLS connections from clients who authenticate themselves using a certificate issued by your trusted CA.
Create a private key and request a certificate for your MySQL Client client
Request a new certificate from your CA to represent your MySQL Client client.
Since you're using MySQL Client, which requires RSA keys, we'll pass the --kty=RSA flag to let step know to generate RSA keys instead of the default EC type.
$ step ca certificate --kty=RSA "myuser" client.crt client.keyYour certificate and private key will be saved in client.crt and client.key respectively.
Open a connection from MySQL Client using mutual TLS
Now, we need only to configure our MySQL Client client to make authenticated requests using our certificate and private key. The CA root certificate will be used to verify that the client can trust the certificate presented by the server.
For additional security, step certificates are signed by an intermediate CA by default rather than the root CA. The intermediate certificate is bundled into your server.crt certificate (configured on the server side).
Unfortunately, MySQL has an outstanding bug that prevents it from being able to read the intermediate certificate out of server.crt. So, we'll have to instead bundle that intermediate CA certificate together with the root CA certificate we saved previously (ca.crt) so that our MySQL client can read it and verify the server certificate was signed by your intermediate CA.
$ step certificate bundle $(step path)/certs/intermediate_ca.crt ca.crt ca-bundle.crtPass your certificate, private key, and the CA bundle to your MySQL client to authenticate your connection over TLS. The SSL mode VERIFY_IDENTITY instructs MySQL to verify that the name in our server certificate matches the hostname for the connection, which offers the tightest security.
$ mysql -h myserver.internal.net -P 4000 -u myuser -p --ssl-mode=VERIFY_IDENTITY --ssl-cert=client.crt --ssl-key=client.key --ssl-ca=ca-bundle.crtIt's also possible to configure those arguments in the [client] section of your my.cnf file to be used on every connection:
#...
[client]
# ...
ssl-mode=VERIFY_IDENTITY
ssl-cert=/path/to/client.crt
ssl-key=/path/to/client.key
ssl-ca=/path/to/ca-bundle.crt
# ...Then, they can be dropped from the CLI client command.
$ mysql -h myserver.internal.net -P 4000 -u myuser -pRead more
Automate certificate renewal
By default, step-ca issues certificates with a 24 hour expiration. Short-lived certificates have many benefits but also require that you renew your certificates each day before they expire. How you renew certificates is often dependent on how you deploy your application. See the step-ca certificate lifecycle management docs for more information.
All documentation content from the Hello mTLS project is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0).
Subscribe to updates
Unsubscribe anytime. See our privacy policy.
© 2024 Smallstep Labs, Inc. All rights reserved.