I've been searching and testing for hours and still can't figure this out. MySQL version 5.7.23 on both slave and master.

Replication over SSL is failing with the following error message:

Slave I/O for channel '': error connecting to master '[email protected]:3306' - retry-time: 60 retries: 1, Error_code: 2026

Replication works fine without SSL, so I know that the replication user and password are correct, and port 3306 is not blocked. I can connect with SSL from the command line with the same user and password combination:

mysql -u replslave1 -pxxxx -h stuff.stuff.com --ssl --ssl-ca='/etc/mysql/master-ca.pem' --ssl-capath='/etc/mysql' --ssl-cert='/etc/mysql/repl1-pub.pem' --ssl-key='/etc/mysql/repl1-priv.pem' --ssl-cipher='DHE-RSA-AES256-SHA'

When I do this from the command line the cipher shows as DHE-RSA-AES256-SHA.

Any ideas are welcome.

  • @hot2use thanks for the edit. What is the markup you use for showing the error message that way? Aug 28, 2018 at 19:18
  • A simple > with an additional space.
    – John K. N.
    Aug 28, 2018 at 19:49

3 Answers 3


Finally! 6 - 8 hours of work later:

The problem in my case was that the slave server has 2 network interfaces and the usable/public IP address is assigned to the second interface. The first, which I assume that MySQL/OpenSSL is using as a default, does not have an IP address.

I solved by adding MASTER_BIND to my CHANGE_MASTER statement.


I feel your pain :-) I was having the exact same issue: manual MySQL SSL connections worked but SSL replication failed to connect with 2026.

Though, I ended up with a different solution. The default generated keys (during MySQL installation), that I had copied to the client, did not have generous enough read-permissions. So this became my solution:

chmod a+r client-key.pem

  • 1
    That may be too much read permissions. You might want to change the ownership of those files instead, probably to mysql:mysql. Aug 31, 2018 at 13:06

I also discovered another cause of this 2026 error: In the directory defined by MASTER_SSL_CAPATH (in 'show slave status' output this appears as Master_SSL_CA_Path) I had generated a new SSL request/public_key/private_key set (for a new client) that were owned by a different user and the private key was not readable by mysql. Once I changed the ownership of those files to mysql:mysql replication started right back up.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.