This is not necessarily going to be a comprehensive post, but I learned somethings about MySQL SSL today that I thought would be worth sharing.
I was setting up a PRM install for a customer and one of the requirements was SSL replication. In this particular case, I had setup PRM first, and then was working to get the other requirements configured. I knew from experience that it was best to ensure SSL was working properly from the command line first before trying to get replication to use it via PRM’s automation that does the CHANGE MASTER for you. Eliminate the variables.
The customer provided me with the CA cert, the private key, and the server key, and this was already working on an existing environment with the same MySQL version. I had already added the relevant config options in the ‘mysqld’ section of the my.cnf:
Now, maybe the rest of the world finds it easy to understand the difference between the server and client keys and certs, and if you need all these options on the client side to connect with SSL to mysql, but I’ve always found it confusing. From what I can tell, the client-side key and cert is really only necessary if you need the server to authenticate the client. If you just need raw encryption without that validation, it’s enough to just give the client the CA cert:
However in my case, I immediately got the dreaded:
ERROR 2026 (HY000): SSL connection error
As is normally the case when one encounters this error, the following steps were taken (in no particular order, or many times in some cases):
I went through a variety of theories before I found the right one. They included:
“Aha!”, you say. chroot, you fool, of course that’s the problem! And indeed it was, but I’m getting ahead of myself. How did I make such a revelation? Well, the openssl cli lets to setup a simple SSL client and server, which turns out to be a great way to verify your SSL environment and keys/certs are working properly. The basic test goes like this:
Start up a basic HTTP-ish server:
/usr/bin/openssl s_server -cert /etc/mysql/ssl/server-cert.pem -key /etc/mysql/ssl/server-key.pem -www
Now run a client against that server:
openssl s_client -CAfile /etc/mysql/ssl/ca-cert.pem -connect 127.0.0.1:4433
If all is working, then your client should output a copy of the server certificate and generally not give any errors. If there are errors, it’s helpful to look at what the server outputs.
In my case, this worked fine. However, once I started suspecting the chroot environment, I was able to quickly start a basic MySQL server outside the chroot and confirm SSL worked fine there. MySQL worked fine outside the chroot, and so did the basic openssl server, so how do I test the chroot environment? By running the openssl s_server in the chroot, of course:
chroot /the/root /usr/bin/openssl s_server -cert /etc/mysql/ssl/server-cert.pem -key /etc/mysql/ssl/server-key.pem -www
Go figure! After realizing the big gap in my script to build the chroot directories, I finally got what I had been looking for:
# mysql --ssl-ca=/data/mysql/etc/mysql/DigiCertCA.pem
--------------Connection id: 101
Current user: root@localhost
<strong>SSL: Cipher in use is DHE-RSA-AES256-SHA</strong>
After this, it was trivial to get replication fully working with SSL. Now that I’ve been through it once, it should be easy to debug in the future.