Bug #29989 | ssl seems not to be working in 5.0.45 | ||
---|---|---|---|
Submitted: | 23 Jul 2007 21:07 | Modified: | 5 Oct 2012 15:37 |
Reporter: | Don Cohen | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Command-line Clients | Severity: | S2 (Serious) |
Version: | 5.0.45 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[23 Jul 2007 21:07]
Don Cohen
[24 Jul 2007 6:21]
Sveta Smirnova
Thank you for the report. This can be duplicate of Bug #26760 Please indicate accurate version of your operating system and MySQL package you use (file name)
[24 Jul 2007 8:45]
Don Cohen
This can be duplicate of Bug #26760 I don't think so. I don't get the same error message and the output of ./mysql --help does include the ssl options. Please indicate accurate version of your operating system and MySQL package you use (file name) # uname -a Linux number8 2.6.20-1.2962.fc6 #1 SMP Tue Jun 19 19:27:14 EDT 2007 i686 i686 i386 GNU/Linux mysql-5.0.45-linux-i686.tar.gz and windows vista mysql-essential-5.0.45-win32.msi
[24 Jul 2007 19:10]
Sveta Smirnova
Thank you for the feedback. I can not repeat described behaviour with indicated binaries: $bin/mysql -uroot --socket=/tmp/mysql_ssmirnova.sock --ssl-ca=/users/ssmirnova/mysql-5.0.45-linux-i686/mysql-test/std_data/cacert.pem --ssl-key=/users/ssmirnova/mysql-5.0.45-linux-i686/mysql-test/std_data/client-key.pem --ssl-cert=/users/ssmirnova/mysql-5.0.45-linux-i686/mysql-test/std_data/client-cert.pem Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 5 Server version: 5.0.45 MySQL Community Server (GPL) Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> \s -------------- bin/mysql Ver 14.12 Distrib 5.0.45, for pc-linux-gnu (i686) using readline 5.0 Connection id: 5 Current database: Current user: root@localhost SSL: Cipher in use is DHE-RSA-AES256-SHA Current pager: stdout Using outfile: '' Using delimiter: ; Server version: 5.0.45 MySQL Community Server (GPL) Protocol version: 10 Connection: Localhost via UNIX socket Server characterset: latin1 Db characterset: latin1 Client characterset: latin1 Conn. characterset: latin1 UNIX socket: /tmp/mysql_ssmirnova.sock Uptime: 2 min 39 sec Threads: 1 Questions: 8 Slow queries: 0 Opens: 11 Flush tables: 1 Open tables: 3 Queries per second avg: 0.050 -------------- mysql> \q Bye Please porvide exact command line you use to connect to the server and certificates you can not connect with which.
[24 Jul 2007 20:11]
Don Cohen
> I can not repeat described behaviour with indicated binaries: > $bin/mysql -uroot --socket=/tmp/mysql_ssmirnova.sock --ssl-ca=/users/ssmirnova/mysql-5.0.45-linux-i686/mysql-test/std_data/cacert.pem --ssl-key=/users/ssmirnova/mysql-5.0.45-linux-i686/mysql-test/std_data/client-key.pem --ssl-cert=/users/ssmirnova/mysql-5.0.45-linux-i686/mysql-test/std_data/client-cert.pem I didn't realize there were such files in the distribution. So I now use those. > Please porvide exact command line you use to connect to the server and > certificates you can not connect with which. I think I did provide the exact command line. I do so now again. In this case I just send examples that contact one machine running 5.0.37 so I'm only showing a problem with the client. But previously I showed the corresponding problem with the server. Here's a new version showing the new client trying to contact that same server with your cert/pem files. === [root@number8 mysql]# bin/mysql --user="a" --password="a" --host=isis.cs3-inc.com Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 264 Server version: 5.0.37-log Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> \q Bye [root@number8 mysql]# bin/mysql --user="a" --password="a" --ssl-ca=./mysql-test/std_data/cacert.pem --ssl-cert=./mysql-test/std_data/client-cert.pem --ssl-key=./mysql-test/std_data/client-key.pem --host=isis.cs3-inc.com ERROR 2026 (HY000): SSL connection error [root@number8 mysql]# uname -a Linux number8 2.6.20-1.2962.fc6 #1 SMP Tue Jun 19 19:27:14 EDT 2007 i686 i686 i386 GNU/Linux [root@number8 mysql]# bin/mysql --version bin/mysql Ver 14.12 Distrib 5.0.45, for pc-linux-gnu (i686) using readline 5.0 [root@number8 mysql]# === and now the same command from another machine (different pem/cert) just to show that the server is running ssl === [root@don-eve ~]# mysql --user="a" --password="a" --host=isis.cs3-inc.com --ssl\ -ca=/etc/pki/tls/cert.pem --ssl-cert=/usr/share/swamp/A-client.pem --ssl-key=/u\ sr/share/swamp/A-client.pem Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 266 to server version: 5.0.37-log Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> \s -------------- mysql Ver 14.7 Distrib 4.1.20, for redhat-linux-gnu (i386) using readline 4.3 Connection id: 266 Current database: Current user: a@cpe-76-80-43-194.socal.res.rr.com SSL: Cipher in use is DHE-RSA-AES256-SHA Current pager: stdout Using outfile: '' Using delimiter: ; Server version: 5.0.37-log Protocol version: 10 Connection: isis.cs3-inc.com via TCP/IP Server characterset: latin1 Db characterset: latin1 Client characterset: latin1 Conn. characterset: latin1 TCP port: 3306 Uptime: 4 days 23 hours 14 min 52 sec Threads: 2 Questions: 457 Slow queries: 0 Opens: 39 Flush tables: 1 Open t\ ables: 18 Queries per second avg: 0.001 -------------- mysql> \q Bye [root@don-eve ~]#
[24 Jul 2007 20:22]
Don Cohen
One more interesting point. I find that I *AM* able to connect to a 5.0.45 server using ssl via the java connector (as modified by a post on http://lists.mysql.com/java), which suggests the problem on the server is specific to something about the mysql command line client. I've also tried running the client under strace and the resulting trace is pretty short. Might that help? I've not tried to strace the server.
[24 Jul 2007 20:40]
Don Cohen
end of straces of client and server which I hope will give someone there a clue where the problem is first client running # bin/mysql --user="root" --password="..." --ssl-ca=./mysql-test/std_data/cacert.pem --ssl-cert=./mysql-test/std_data/client-cert.pem --ssl-key=./mysql-test/std_data/client-key.pem === open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 4 read(4, "\251\370\217[u8%N\242\353\260\364\351\253o\354t\322\322"..., 32) = 32 time(NULL) = 1185307923 open("/etc/localtime", O_RDONLY) = 5 fstat64(5, {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x22c000 read(5, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0"..., 4096) = 2819 close(5) = 0 munmap(0x22c000, 4096) = 0 time(NULL) = 1185307923 time(NULL) = 1185307923 time(NULL) = 1185307923 open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 5 read(5, "\232\10Oe\31\321&\37\25\241\333>\303\250\331\321\23\246"..., 32) = 32 send(3, "\26\3\1\0Y\1\0\0U\3\1\245\275\275\177tlor\356B\301\301"..., 94, 0) = 94 recv(3, "\26", 1, MSG_PEEK) = 1 ioctl(3, FIONREAD, [1408]) = 0 recv(3, "\26\3\1\0J\2\0\0F\3\1\337\334\304\2448w\264\323\2\321a"..., 1408, 0) = 1408 time(NULL) = 1185307923 time(NULL) = 1185307923 close(4) = 0 shutdown(3, 2 /* send and receive */) = 0 close(3) = 0 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc1d000 write(2, "ERROR 2026 (HY000): ", 20ERROR 2026 (HY000): ) = 20 write(2, "SSL connection error", 20SSL connection error) = 20 write(2, "\n", 1 ) = 1 write(1, "\7", 1) = 1 close(5) = 0 munmap(0xc1d000, 4096) = 0 _exit(1) = ? === end of strace of server === read(4, "-----BEGIN RSA PRIVATE KEY-----\n"..., 4096) = 493 _llseek(4, -461, [32], SEEK_CUR) = 0 read(4, "MIIBOgIBAAJBANjbaChJhE3WD1y8PZqr"..., 4096) = 461 _llseek(4, 493, [493], SEEK_SET) = 0 close(4) = 0 munmap(0x50f000, 4096) = 0 open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 4 read(4, "\313c\303H\327(7^\333\326N\364\235_\227P6i\3725_&\204@"..., 32) = 32 time(NULL) = 1185308825 open("/etc/localtime", O_RDONLY) = 5 fstat64(5, {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xaed000 read(5, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0"..., 4096) = 2819 close(5) = 0 munmap(0xaed000, 4096) = 0 time(NULL) = 1185308825 time(NULL) = 1185308825 time(NULL) = 1185308825 open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 5 read(5, "\201\372\363r\326\261*[\321\2533\4yB\346\250\366W\25l\323"..., 32) = 32 send(3, "\26\3\1\0Y\1\0\0U\3\1}\330\346\23:wO\26I\n\206\302\344"..., 94, 0) = 94 recv(3, "\26", 1, MSG_PEEK) = 1 ioctl(3, FIONREAD, [1408]) = 0 recv(3, "\26\3\1\0J\2\0\0F\3\1\334\217\232\232\21r \"\21\373\307"..., 1408, 0) = 1408 time(NULL) = 1185308825 time(NULL) = 1185308825 close(4) = 0 shutdown(3, 2 /* send and receive */) = 0 close(3) = 0 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aa000 write(2, "ERROR 2026 (HY000): ", 20ERROR 2026 (HY000): ) = 20 write(2, "SSL connection error", 20SSL connection error) = 20 write(2, "\n", 1 ) = 1 write(1, "\7", 1) = 1 close(5) = 0 munmap(0x2aa000, 4096) = 0 _exit(1) = ?
[25 Jul 2007 8:06]
Sveta Smirnova
Thank you for the feedback. If I understood correct you have problems when connect from same machine. Please also provide output of SHOW GRANTS FOR a@localhost; and your configuration file.
[25 Jul 2007 8:26]
Don Cohen
> If I understood correct you have problems when connect from same machine. So far I cannot use either the client or the server for either linux or windows mysql 5.0.45 for an ssl connection. It's not only a problem with the same machine acting as server and client. > Please also provide output of SHOW GRANTS FOR a@localhost; and your > configuration file. This seems to be asked under the false impression that the problems only occurs when the same machine acts as server and client. In the previous entry where I sent the strace output I was using both client and server on the same (linux) machine. But that was not user a, so perhaps you want this for the machine where the user was a, which was running 5.0.37 ? Instead I do this on the linux machine used for the strace outputs. The user there was root@localhost. show grants for root@localhost; +----------------------------------------------------------------------------------------------------------------------------------------+ | Grants for root@localhost | +----------------------------------------------------------------------------------------------------------------------------------------+ | GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY PASSWORD '...' WITH GRANT OPTION | +----------------------------------------------------------------------------------------------------------------------------------------+ I don't even think there is a configuration file. Or if there is, I don't think I've changed it. I just followed the directions on the web page to install this: gunzip /tmp/mysql-5.0.45-linux-i686.tar.gz groupadd mysql useradd -g mysql mysql cd /usr/local tar xf /tmp/mysql-5.0.45-linux-i686.tar ln -s mysql-5.0.45-linux-i686/ mysql cd mysql chown -R mysql . chgrp -R mysql . scripts/mysql_install_db --user=mysql chown -R root . chown -R mysql data bin/mysqld_safe --user=mysql & ./bin/mysqladmin -u root password '...' bin/mysqld_safe --user=mysql --log-bin --log & and then later started adding the ssl arguments
[6 Aug 2007 12:37]
Sveta Smirnova
Thank you for the feedback. > I find that I *AM* able to connect to a 5.0.45 server using ssl via the java connector Please also provide part of Java program with all connection settings you used to successfully connect to a 5.0.45 server using ssl
[7 Aug 2007 2:26]
Don Cohen
> I find that I *AM* able to connect to a 5.0.45 server using ssl via the java connector Please also provide part of Java program with all connection settings you used to successfully connect to a 5.0.45 server using ssl I guess this is what you want: public static Connection dbConnect( String dbName) throws Exception // ignore dbname argument --> Sonario.dbname { Connection dbConnect = null; Connection cn = new Connection(); String url = "jdbc:mysql://" + Sonario.hostname + ":3306/" + Sonario.dbname + "?useSSL=true&requireSSL=true&requireSSLcert=false"; dbg("LeoLIB dbConnect " + Sonario.hostname); //AdoUtil.registerDriver("sun.jdbc.odbc.JdbcOdbcDriver"); //("jdbc:odbc:cnn1", null, null); cn.open (url, user, pass); // When DB procedures become available &&& // do proc(cn, user, pass) - associate session with connection_id() dbg("LeoLIB dbConnect = " + cn); dbConnect = cn; return dbConnect; }
[7 Aug 2007 8:41]
Sveta Smirnova
Thank you for the feedback. Seems your Java program does not require a certificate from the server: requireSSLcert=false (I also looked into you patch submitted to http://lists.mysql.com/internals/34026). Please try to connect via mysql without --ssl-ca option (or its --ssl-ca=/dev/null replacement) and in case of success provide both server and client ssl-ca
[7 Aug 2007 12:17]
Don Cohen
Seems your Java program does not require a certificate from the server: That is correct, and it seems likely to me that the problem is related to that, but I can't tell whether in the server, client or both. requireSSLcert=false (I also looked into you patch submitted to http://lists.mysql.com/internals/34026). Please try to connect via mysql without --ssl-ca option (or its --ssl-ca=/dev/null replacement) and in case of success provide both server and client ssl-ca I think this is what you're asking for: # bin/mysql --user="root" --password="..." --ssl-cert=./mysql-test/std_data/client-cert.pem --ssl-key=./mysql-test/std_data/client-key.pem ERROR 2026 (HY000): SSL connection error (as opposed to # bin/mysql --user="root" --password="..." Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 23 Server version: 5.0.45 MySQL Community Server (GPL) )
[8 Aug 2007 9:32]
Sveta Smirnova
Thank you for the feedback. Please upload your configuration file. Also please turn on --log-warnings (which will turn on connection errors logging) option and upload error log file.
[8 Aug 2007 12:29]
Don Cohen
> Please upload your configuration file. Also please turn on --log-warnings (which will turn on connection errors logging) option and upload error log file. As usual I'm guessing at how to interpret your request. Here's what I've now done: ./bin/mysqladmin -u root --password="..." shutdown bin/mysqld_safe --user=mysql --ssl-ca=/etc/pki/tls/cert.pem --ssl-cert=/usr/share/swamp/A-client.pem --ssl-key=/usr/share/swamp/A-client.pem --log-warnings bin/mysql --user="root" --password="WareTrigger" --ssl-cert=./mysql-test/std_data/client-cert.pem --ssl-key=./mysql-test/std_data/client-key.pem (which results in ERROR 2026 (HY000): SSL connection error) As far as I know there is no configuration file. The error log file, number8.err, ends with 070808 5:15:17 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete 070808 05:15:17 mysqld ended 070808 05:16:15 mysqld started 070808 5:16:16 InnoDB: Started; log sequence number 0 49825 070808 5:16:16 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.45' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server (GPL) === I would have thought that the strace I sent earlier would be much more useful than the error log. Have you been able to reproduce this on your own machines? Have you tried starting from the distribution as I did. Since I get the same results in both linux and windows it seems like this should be easy to reproduce.
[9 Aug 2007 18:07]
Sveta Smirnova
Thank you for the feedback. I am trying all time to repeat the problem on my side, but had no success: all connections with valid certificates were successfull. You showed you start mysqld as bin/mysqld_safe --user=mysql --ssl-ca=/etc/pki/tls/cert.pem --ssl-cert=/usr/share/swamp/A-client.pem --ssl-key=/usr/share/swamp/A-client.pem --log-warnings Problem here: mysqld uses certificate authority /etc/pki/tls/cert.pem, but clients tries to connect using keys provided with our test suite: bin/mysql --user="root" --password="WareTrigger" --ssl-cert=./mysql-test/std_data/client-cert.pem --ssl-key=./mysql-test/std_data/client-key.pem This should raise connection error, because our certificates have been signed by our certificate authority and not by yours. Please try to repeat configuration when you connect to 5.0.37 successfully, indicate how you start mysqld/connect to mysqld in case of 5.0.37. Repeat same steps with 5.0.45 and if you still get connection error upload your keys and certificates (I mean create test ones with dummy values, but bug is repeatable with).
[10 Aug 2007 0:15]
Don Cohen
> Problem here: mysqld uses certificate authority /etc/pki/tls/cert.pem, but clients tries to connect using keys provided with our test suite: My mistake. Here's a corrected version. === # bin/mysqld_safe --user=mysql --ssl-ca=/etc/pki/tls/cert.pem --ssl-cert=/usr/share/swamp/A-client.pem --ssl-key=/usr/share/swamp/A-client.pem --log-warnings & [first with the same arguments as above] # bin/mysql --user="root" --password="..." --ssl-ca=/etc/pki/tls/cert.pem --ssl-cert=/usr/share/swamp/A-client.pem --ssl-key=/usr/share/swamp/A-client.pem ERROR 2026 (HY000): SSL connection error [then without ssl-ca] # bin/mysql --user="root" --password="WareTrigger" --ssl-cert=/usr/share/swamp/A-client.pem --ssl-key=/usr/share/swamp/A-client.pem ERROR 2026 (HY000): SSL connection error > Please try to repeat configuration when you connect to 5.0.37 successfully, indicate how you start mysqld/connect to mysqld in case of 5.0.37. Repeat same steps with 5.0.45 and if you still get connection error upload your keys and certificates (I mean create test ones with dummy values, but bug is repeatable with). Here's transcript from old version that works: === [root@don-eve ~]# mysql --version mysql Ver 14.7 Distrib 4.1.20, for redhat-linux-gnu (i386) using readline 4.3 [root@don-eve ~]# mysql --user="a" --password="..." --host=isis.cs3-inc.com --ssl-ca=/etc/pki/tls/cert.pem --ssl-cert=/usr/share/swamp/A-client.pem --ssl-key=/usr/share/swamp/A-client.pem Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 2213 to server version: 5.0.37-log === I now copy those files above to the machine with the new version: === [root@number8 mysql]# scp don@don-eve.dyndns.org:/etc/pki/tls/cert.pem ca-file [root@number8 mysql]# scp don@don-eve.dyndns.org:/usr/share/swamp/A-client.pem non-ca-file === and try to use the same command with the new files === [root@number8 mysql]# bin/mysql --version bin/mysql Ver 14.12 Distrib 5.0.45, for pc-linux-gnu (i686) using readline 5.0 [root@number8 mysql]# bin/mysql --user="a" --password="..." --host=isis.cs3-inc.com --ssl-ca=ca-file --ssl-cert=non-ca-file --ssl-key=non-ca-file ERROR 2026 (HY000): SSL connection error === However, now when I leave off the --ssl-ca argument: === [root@number8 mysql]# bin/mysql --user="a" --password="..." --host=isis.cs3-inc.com --ssl-cert=non-ca-file --ssl-key=non-ca-file Welcome to the MySQL monitor. Commands end with ; or \g. === What does all that mean? Does leaving out the argument mean not to check certificates? That's not good enough on the new server.
[10 Aug 2007 7:03]
Sveta Smirnova
Thank you for the feedback. So all finally working? I'll close the report as "Not a Bug" > Does leaving out the argument mean not to check certificates? Yes, this is expected behaviour. For reason see bug #25309
[10 Aug 2007 12:30]
Don Cohen
> So all finally working? I'll close the report as "Not a Bug" Not at all! I still see - problem with client - cannot connect even to old server with --ssl-ca Don't you consider that a bug? - problem with either client or server (can't tell which, maybe both) cannot connect from new client to new server with ssl at all. Both of these are demonstrated in the last entry ([10 Aug 2:15] Don Cohen)
[10 Aug 2007 12:36]
Sveta Smirnova
Thank you for explanation. We can not repeat error with valid certificates created on our side. Please upload your keys and certificates to we can see what is wrong.
[10 Aug 2007 15:32]
Don Cohen
in ealier post you see a use of ca-file - this is it
Attachment: ca-file (application/octet-stream, text), 417.81 KiB.
[10 Aug 2007 15:33]
Don Cohen
in earlier post you see a use of non-ca-file - this is it
Attachment: non-ca-file (application/octet-stream, text), 4.59 KiB.
[10 Aug 2007 15:34]
Don Cohen
files used as arguments to the commands in previous post now uploaded
[13 Sep 2007 0:40]
Don Cohen
Is anyone paying attention to this bug? Now that I have built another 5.0.45 from source (see bug 30846) I thought I'd try that one. Unlike the other 5.0.45's that one does at least connect to itself. This is all getting so confusing that I systematically tried a bunch of clients connecting to a bunch of servers. Here's the result. server 4.1.20 5.0.18 5.0.37 5.0.45l 5.0.45w 5.0.45S client 4.1.20 + + + - - + 5.0.37 + - + - - - 5.0.45l - - - - - - 5.0.45w - - - - - - 5.0.45S - + - - - + 4.1.20 = fc4 pentium 4 yum 5.0.18 = SUSE Linux Enterprise Server 10 (ia64) built from source (client built without ssl support!) 5.0.37 = fc7 amd x86_64 yum 5.0.45l = fc6 intel 32 mysql-5.0.45-linux-i686.tar 5.0.45w = windows mysql-essential-5.0.37-win32.msi 5.0.45S = SUSE Linux Enterprise Server 10 (ia64) built from source + = connect with ssl successful (check cipher with \s) - = connect with ssl UNsuccessful, but successful without ssl I hope that at least clarifies the data. The pattern and cause is still beyond me. The -ssl arguments are always the same for a given machine (always use the same files for clients as for the server). I think that many of the machines use the same files, but not all. If it becomes important to identify which machines use which files I can reconstruct that but for now I assume the problem is not in those files. If you think the problem might be in the files then you can give me the files you want me to try. I look forward to any hypotheses.
[4 Dec 2007 15:59]
Bart Baars
I think I got it.. MySQL expects the ca-cert to be self-signed, but this doesn't have to be true.. If I all understood correctly, you should issue the ca-certificated that signed the client/server certificate. But when you used a subordinate ca (SubCA), this ca-cert will not be self signed (only the rootca-certificate is selfsigned). I noticed I am never able to setup a ssl-connection when using a SubCA-certificate. The rootca-certificate always works.
[4 Dec 2007 18:22]
Don Cohen
I'm trying to understand the last comment. There are two different programs using two different certs, right? Is it the client that expects the server cert to be self signed, or the server that expects the client cert, or the client cert that expects its own or the server that expects its own? Which argument of which program should I change? Also, is it the case that this is a bug that was introduced at some point in time, so that earlier versions work for any certs? I'm pretty sure that in my table, every use of a client or server in the same row or column uses the same set of ssl- arguments. If nothing changed in the software then, as I understand your last post, either the rows or the columns should have been always working or nonworking. Is that correct? But that's not what the table shows. BTW I also believe that most of the clients/servers in different rows/columns use the same ssl- arguments (meaning that the files were the same on the different machines involved), and that would lead me to expect (if your diagnosis is correct) that those different columns/rows should also be the same.
[4 Dec 2007 19:04]
Bart Baars
Both the server and the client need 3 files: 1. a private key (--ssl-key) 2. a signed certificate (--ssl-cert) 3. The certificate of the Certificate Authority (CA) that signed the certificate in (2). (--ssl-ca) I believe MySQL expects the CA certificate (certificate of the CA) to be self-signed (the issuer is the same as the DN in the certificate). But this does not have to be the case. A Subordinate CA (SubCA) can also sign certificates. But the SubCA's certificate is not self-singed, it is signed by the RootCa. So, according to (3) you should use the SubCa's certificate. But MySQL expects this certificate to be self-signed, which is not the case if you use a SubCA. And that's why this probably is a bug. I tested this on RHEL5.0, which ships with MySQL-server 5.0.22. Using a self-signed certificate for the server solved it for me (but this is not a solution, it conflicts with (3)!) In a CA certificate or SubCA certificate, the CA-property is set to "TRUE" (under X509v3 Basic Constraints). This field can be used to see if a certificate actually from a (Sub)CA. Or a certificate chain should be added as an option. That would be a more appropriate way of checking the CA-certificate. So, to wrap it up: I think MySQL currently has a bug in the way it check if the CA-certificate actually is created by a CA. But, please note; I am not a developer and haven't looked in the code. MySQL has to confirm my thoughts!
[4 Dec 2007 19:23]
Don Cohen
You say I believe MySQL expects the CA certificate ... But we're talking about two programs communicating here, BOTH written by mysql, the mysql server and the mysql client. Do you mean the server expects something or the client expects it, or both? And does that program expect this of its OWN certs or of the OTHER program's certs, or both? Using a self-signed certificate for the server solved it for me Ok, at least this tells me to change the argument on the server, rather than the client.
[4 Dec 2007 19:37]
Bart Baars
Both the server and the client require: - a private key (one for the server and a different one for the client) - a signed certificate (based on (1), so they differ per client/server) - a CA certificate, has to be the same on both the client and server.. That's pretty basic PKI/certificate theory ;)
[4 Dec 2007 19:59]
Don Cohen
I understand that they both take all three arguments. But the BUG could be only that the client requires the server cert to have some property, or only that the server requires its own cert to have some property or only that the client requires ... So there are 4 possible bugs. And 15 possible sets of those bugs, excluding the empty set.
[5 Dec 2007 9:00]
Bart Baars
That's why (hopefully) somebody from MySQL will take a look at this ;)
[4 Sep 2012 20:06]
Sveta Smirnova
Thank you for the feedback. This bug was assigned to an engineer who left the company, therefore we missed it. Please try it with one of current versions: 5.1.65 and 5.5.27 and if problem still exists provide certificates for both server and client. I can not connect to server using files provided and it is expected: they are supposed to have same ssl-ca
[5 Oct 2012 1:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
[5 Oct 2012 15:37]
Don Cohen
Sorry it took so long to get back to you, and thanks for reminding me after a month - though after 5 years, that doesn't seem so long! I was able to find some machines still using 5.0.45 and I still have problems there, but would you really try to provide fixes for 5.0.45 if the problem could be solved? Probably not. And, having lived with the problem for 5 years, I'm obviously not holding my breath for such a fix anyway.