MySQL Bugs: #25309: SSL connections without CA certificate broken since MySQL 5.0.23

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:	None
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

Description:
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).

It could even be as simple as this (theoretically) :

case X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN:
    ok= 1 if (!mysql->options.ssl_verify_server_cert);
    break;

however, this would mean more work ofcourse for the mysql->options stuff.

Thank you for the report.

Verified as described.

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).

Currently,

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.

MySQL is now using the yaSSL implemtation of SSL as default and that is why you see this change after 5.0.22

Allright,

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).

Yes, it might work in a build of MySQL that has been compiled and linked with the OpenSSL libraries.

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:

  http://lists.mysql.com/commits/23130

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

Pushed into 5.0.40

Pushed into 5.1.18-beta

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.