3

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.

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

3 Answers 3

Reset to default
1

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.

Improve this answer
0

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

Improve this answer
1
  • 1
    That may be too much read permissions. You might want to change the ownership of those files instead, probably to mysql:mysql.
    – Mitch Claborn
    Commented Aug 31, 2018 at 13:06
0

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.

Improve this answer

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.