When trying to connect to mysql-5.5 with ssl enabled with either HeidiSQL or Sequal Pro, an error is received. (I know 5.5 is marked as unstable, but 5.1 is EOL: http://www.mysql.com/support/eol-notice.html. Also, the same issue was replicated with 5.1.) For example when trying to connect with ssl enabled on HeidiSQL the following error is seen: "SQL Error (2026) in statement #0: SSL error: unknown error number" After some trial and error, I discovered that this can be resolved with a different compile time option for mysql. Currently used option: -DWITH_SSL=system Option that corrects this issue: -DWITH_SSL=bundled After compiling again with the corrected option both HeidiSQL and Sequal Pro were able to connect without issue using SSL. Thanks!
(In reply to bjtaylor from comment #0) > Option that corrects this issue: -DWITH_SSL=bundled That looks like a pretty bad workaround. Instead of the newer dev-libs/openssl which might fix such bugs as might have recently caught the world unawares, you want to instead use the bundled copy of openssl which may or may not have been patched?
I cannot repeat this. I've tested with SQLyog and HeidiSQL and received SSL connections with 5.5.37-r1 w/ openssl. "SQL Error (2026) in statement #0: SSL error: unknown error number" usually means there is a configuration issue. Either on the client or server side
Point taken. I agree with you, fixing the issue between openSSL and MySQL would be ideal, but honestly, I don't know where the fault lies. (Is it the way MySQL implemented openSSL or is it a bug in openSSL itself?) However, I will point out one thing: the bundled version of SSL in MySQL is not openSSL, it is yaSSL. (http://dev.mysql.com/doc/refman/5.5/en/configuring-for-ssl.html) We realized that this was a compile time issue when we noted that the aforementioned MySQL clients worked with MySQL in other distributions, but not in Gentoo. And so, then the question became "what is different?" We tried different versions of openSSL (both older and newer than what was in the other distro), and still no luck. Only by switching to yaSSL were we able to resolve the issue. I personally don't know the maintainers of MySQL or their processes, but I would presume that the MySQL team does a fairly good job of keeping yaSSL updated with their releases. MySQL version 5.5.37 (released 2014-03-27) is using a version of yaSSL that was released on 12/5/2013. This seems fairly updated to me. So... long story short. I'll report this bug over at MySQL as well, but I still think that using the bundled version of yaSSL is a good idea. Thanks.
(In reply to bjtaylor from comment #3) > Point taken. I agree with you, fixing the issue between openSSL and MySQL > would be ideal, but honestly, I don't know where the fault lies. (Is it the > way MySQL implemented openSSL or is it a bug in openSSL itself?) > So... long story short. I'll report this bug over at MySQL as well, but I > still think that using the bundled version of yaSSL is a good idea. If you really want yaSSL, then set -ssl as a USE flag. That is all that it takes on 5.5+
In chatting with Brian, it seems that the difference between what he did, and what I was trying was that I was wanting to connect without having to copy any certs to the client. He had all 3 cert fields populated, while I didn't have any populated. Thank you Brian for clarifying that point for me. Also, I was not aware of the -ssl use flag. I am still new to gentoo, and although I knew about use flags, I couldn't find one that matched what I needed. Using that use flag solved my issue, and everything now works as expected. Thanks all for your time.
