EDIT: It looks like RedHat pushed a new build that fixes the issue ->
If all of your MYSQL SSL clients and replication just broke, I'm guessing that you're running RedHat, CentOS, or something derived from RedHat. In short, RH modified OpenSSL to reject Diffie Hellman (DH) keysizes less than 768 bits. Note that this is not the length of your private key. This is the DH key which is used in Perfect Forward Secrecy.
Someone please correct me if I'm wrong, but selecting which PFS ring (and hence keysize) to use is a function of the application making the SSL socket request. Therefore, you'll need an updated version of Percona or MySQL community to fix this with PFS ciphers.
One option is to use a secure, symmetric cipher in your configs. We went this route to keep things going. On CentOS 6, one of the best choices is Camellia 128. If you're doing command line work, add this to the argument list:
You should also be able to add that to your my.cnf and get things going that way, too.
The error thrown in MySQL is error 2026, which is a catch-all for all SSL errors. It throws that error for bad certs, bad permissions, bad anything....which makes things difficult to track down. That said, if things broke in the past few days (June 4th), it's probably the cipher problem. We tracked it down in the yum log (openssl-1.0.1e-30.el6.9.x86_64). Whenever something suddenly stops working, always check the yum log first. Thanks RedHat!
6/7/2015 12:04:12 pm
Note that if you're editing my.cnf, the cipher seems to be case-sensitive (unsure about CLI invocation). I had to use:
6/15/2015 04:46:06 am
You could also disable Diffie Hellman key exchange by adding :-DH:-ECDH to the end of your ssl-cipher config in your my.cnf. Although I believe you then give up forward secrecy in exchange for using a different key exchange method. Ideally, this is fixed in mysql soon so we should watch for that fix and then go back and remove these ssl-cipher config crutches.
6/17/2015 08:21:41 am
We were bitten by this recently in our php based web application. The solution (since we were using PDO DB connections) was to build our connections like this:
6/17/2015 09:58:04 pm
We have a django application that connects to a remote MySQL server over SSL. Until this upgrade to OpenSSL, the connection to mysql worked well. Now it does not because ssl_cipher is not a valid option for mysql.connector.django, the python3 driver I use for communicating with mysql.
6/17/2015 10:21:33 pm
For python, you can use the 'options_file' connection argument to include your my.cnf file, and 'option_groups' argument to specify the '[client]' section. Then just edit your my.cnf (as stated by David Young above) and add 'ssl-cipher=CAMELLIA128-SHA' to the [client] section of my.cnf.
6/18/2015 11:20:43 am
Thanks for that John. Using the options file did not fix the problem completely. It turns out ciphers value set in my.cnf is not used by the mysql.connector.django.
6/18/2015 11:32:46 am
Forgot to include versions of packages I am using
6/23/2015 12:56:33 pm
Yes... I just updated for CentOS6 as well and looks to be fixed.
7/1/2015 01:12:59 am
Thanks for this great post. Percona just released Percona-Server 5.6.25-73.0 today which fixes this issue. Tested and confirmed working! See changelog:
Comments are closed.
A NOLA native just trying to get by. I live in San Francisco and work as a digital plumber for the joint that runs this thing. (Square/Weebly) Thoughts are mine, not my company's.