Bug #25309 SSL connections without CA certificate broken since MySQL 5.0.23
Submitted: 28 Dec 2006 13:02 Modified: 1 May 2007 14:14
Reporter: Wouter de Jong Email Updates:
Status: Closed Impact on me:
Category:MySQL Server: Command-line Clients Severity:S3 (Non-critical)
Version:5.0.23 OS:Linux (Linux / FreeBSD)
Assigned to: Magnus Blåudd CPU Architecture:Any
Tags: CA, self signed certificate, SSL

[28 Dec 2006 13:02] Wouter de Jong
Since MySQL 5.0.23, it is no longer possible to use --ssl-ca=/dev/null on the client. This works with MySQL 5.0.22 clients and lower.

This is needed if you don't want to verify SERVER certificates.
You can discuss whether this is very secure though, but that's not the point here :)

The option 'ssl_verify_server_cert' is a bit misleading.

The situation :

Server has a certificate signed by eg. GeoTrust, which is a direct root CA (Equifax).
Client connects as 'mysql -h server --ssl-ca=/dev/null -p', since it has not installed a file with the root-CA. (the default).

This stopped working since MySQL Client version 5.0.23.

Reason is :

vio_verify_callback: enter: ok: 0, ctx: 0xbfbfdab0
vio_verify_callback: info: cert: /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
vio_verify_callback: error: verify error: 19, 'self signed certificate in certificate chain'
vio_verify_callback: exit: 0

Which gives a failure for SSL_do_handshake.

Ofcourse, it is not really a self-signed certificate, but it cannot verify the cert since it has no root CA file to match it with.

In my opinion, option ssl_verify_server_cert should be renamed to ssl_verify_server_name (or something like that, defaults to FALSE) and then have ssl_verify_server_cert defaults to TRUE.

ssl_verify_server_name should then verify the CommonName.
When ssl_verify_server_cert is set to FALSE, allow it to bypass whatever error is acceptable (self-signed, expired, etc).

Many popular tools allow you to do this (for example : wget).

How to repeat:
See description :)

Suggested fix:
Create a new option to allow bypass of certificate validation (defaults to false).
[28 Dec 2006 13:17] Wouter de Jong
It could even be as simple as this (theoretically) :

    ok= 1 if (!mysql->options.ssl_verify_server_cert);

however, this would mean more work ofcourse for the mysql->options stuff.
[28 Dec 2006 14:59] Sveta Smirnova
Thank you for the report.

Verified as described.
[3 Jan 2007 9:48] Axel Schwenke
I was not able to reproduce this with 5.0.34bk. I can still connect without a valid CA cert on the client. Maybe this depends on the openssl version, not MySQL. I'm using openssl-0.9.7d-15 from SuSE Linux 9.1 (yes, this is pretty old).
[8 Jan 2007 20:50] Wouter de Jong

I'm not able to try 5.0.xx BitKeeper versions at the moment, or are there snapshots available ?
Could you try 5.0.23 (or .27) ?

However, the reason I mentioned it is broken 'since' MySQL 5.0.23, is that when I replace a 5.0.23+ build with 5.0.22 or lower, it spontaneously works.
So it really is something with MySQL.

I've also tried this on both Linux and FreeBSD, with different openssl version's (all in 0.9.7 series though)

It really came after the changes for --ssl-verify-server-cert where implemented (which is in MySQL 5.0.23) : 

Added the --ssl-verify-server-cert option to MySQL client programs. This option causes the server's Common Name value in its certificate to be verified against the hostname used when connecting to the server, and the connection is rejected if there is a mismatch. Added MYSQL_OPT_SSL_VERIFY_SERVER_CERT option for the mysql_options() C API function to enable this verification. This feature can be used to prevent man-in-the-middle attacks. Verification is disabled by default.
[17 Jan 2007 11:37] Magnus Blåudd
MySQL is now using the yaSSL implemtation of SSL as default and that is why you see this change after 5.0.22
[17 Jan 2007 12:05] Wouter de Jong

But why does it happen if i still link to OpenSSL ? :)
And should it not also work with yaSSL ? :)

I'll try 5.0.33 asap, however after some more tests I think the main problem lies on FreeBSD and not on Linux (any longer).
[26 Jan 2007 9:00] Magnus Blåudd
Yes, it might work in a build of MySQL that has been compiled and linked with the OpenSSL libraries.
[28 Mar 2007 10:24] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:


ChangeSet@1.2457, 2007-03-28 12:23:55+02:00, msvensson@pilot.blaudden +3 -0
  Bug#25309 SSL connections without CA certificate broken since MySQL 5.0.23
   - Turn off verification of peer if both ca_path and ca_file is null
     i.e from only passing --ssl-key=<client_key> and --ssl-cert=<client_cert>
     to the mysql utility programs.
     The server will authenticate the client accoring to GRANT tables
     but the client won't authenticate the server
[6 Apr 2007 17:21] Bugs System
Pushed into 5.0.40
[6 Apr 2007 17:24] Bugs System
Pushed into 5.1.18-beta
[1 May 2007 14:14] Paul DuBois
Noted in 5.0.40, 5.1.18 changelogs.

If you use SSL for a client connection, you can tell the client not
to authenticate the server certificate by specifying neither --ssl-ca
nor --ssl-capath. The server still verifies the client according to
any applicable requirements established via GRANT statements for the
client, and it still uses any --ssl-ca/--ssl-capath values that were
passed to server at startup time.