Why am I connecting securely to MySQL when I don't have client certificates? I don't understand the MySQL documentation for encrypted connections. The server is configured with certificates, and unless I am misreading it, the documentation says that the client must have certificates as well.

But, if I start the client with 'mysql --ssl' then \s reports that the connection is SSL encrypted using DHE-RSA-AES256-GCM-SHA384 even though I haven't used any certificates with the client. /etc/my.cnf.d/client.cnf does not have any certificates in the [client] section, and I don't have a .my.cnf

How is that possible that I am connected with SSL? Is it not really encrypted?
Yes the connection is encrypted. I think you are getting a few things mixed up here. Let me try to simplify it for you:

SSL is a protocol for exchanging data across a secure network, and in order to establish a connection, the server must have a certificate to use. In order to obtain a certificate you must be issued one. This is generally done by a Certificate Authority (CA) or by using a self-signed one, but we will keep it simple here and stick with CA's. 

If the certificate you used when setting up SSL is valid, and is trusted by the client attempting to establish a connection, then the connection attempt should succeed. The client does not need to present a certificate here, but it does need to trust the issuer of the certificate. This is generally done by having a copy of the CA certificate on your machine and verifying that the certificate presented by the server is signed/issued by the CA.This corresponds roughly to the --ssl-mode=VERIFY_CA and --ssl-mode=VERIFY_IDENTITY (which checks that the host name in the certificate matches the server you are trying to connect to).

MySQL allows the client to select the certificate to use when verifying the identity of the server using the --ssl-ca, --ssl-cert and --ssl-key options and in order for the transport connection to be successful, the certificate presented by the client must be issued by the same CA that issued the server certificate. This is optional, and if you don't present one then the client will look for a corresponding certificate in its store.

Additionally, once you have established an SSL connection you can authenticate an account using certificates (generally using some kind of PKI technology) which would essentially replace using passwords to log in - but the key thing to understand here is that by the time the process gets to the point where you are attempting to log in, the SSL connection has already been established. When you use this method, you generally find that the client certificates have been issued by the same CA as the one that issued the server certificate.

I use the following analogy to explain it to people I teach:


  When my daughter was born the only people she knew she could trust was her mother and me. Then as she got older and more people came into her life we told her who she could and couldn't trust. In this scenario, my wife and I act as the Certificate Authority verifying the trustworthiness of others. If we have not told our daughter she can trust someone then she will not speak to them, much like a how a client will act if it does not trust a server.


The topic of certificates is quite extensive but the key for you is to understand the difference between the client trusting the server enough to establish a secure connection and you then authenticating across that connection using a client certificate.