Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I want my webserver to speak to the MySQL database server over an SSL connection. The Webserver runs CentOS5, the Database Server runs FreeBSD. The certificates are provided by a intermediate CA DigiCert.

MySQL should be using ssl, according to my.cnf:

# The MySQL server
port            = 3306
socket          = /tmp/mysql.sock
ssl-capath = /opt/mysql/pki/CA
ssl-cert = /opt/mysql/pki/server-cert.pem
ssl-key = /opt/mysql/pki/server-key.pem

When I start MySQL, the daemon starts without errors. This suggests that the certificate files are all readable.

But when I try to connect from the webserver to the database server, I get an error:

[root@webserver ~]# mysql -h -u user -p
ERROR 2026 (HY000): SSL connection error

And if I try to debug further with openssl:

[root@webserver ~]# openssl s_client -connect 0>/dev/null
15706:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:588:

Is this a valid way to test the SSL connection to a MySQL database server? The SSL23_GET_SERVER_HELLO:unknown protocol message is strange since this typically what you would see if you were speaking SSL on a port intended for non-SSL traffic.

This same openssl command seems to work fine with LDAP & HTTP servers:

$ openssl s_client -connect  0>/dev/null
depth=2 /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
$ openssl s_client -connect  0>/dev/null
depth=0 /DC=org/DC=example/OU=Services/
share|improve this question

3 Answers 3

up vote 3 down vote accepted

Answering my own question. If you have a better answer with good, authoritative sources please post an answer.

Short answer; No, OpenSSL cannot be used to debug MySQL SSL connections. This is because MySQL starts the session using plaintext and switches over to SSL afterwards.

In reading, it almost looks like MySQL starts off with a plaintext connection, and then the actual SSL is initiated afterwards. This explains how MySQL is able to listen on one port (port 3306) for both plaintext and encrypted connections. Compare this to a HTTP or LDAP server, where one port is used for plaintext connections and a second port is used for encrypted connections.

For an unencrypted connection the server starts with its Initial Handshake Packet: ... and the client returns its Handshake Response Packet:

If client wants to do SSL and the server supports it, it would send a SSL Request Packet with the CLIENT_SSL capability enabled instead:

The rest of the communication is switch to SSL:

share|improve this answer
This is the same as how SMTP works when you use STARTTLS, and it also permits you to use encrypted and unencrypted connectiosn on the same port. – Synchro Jan 26 at 21:34
Hm, I suppose the behavior I'm talking about is how STARTTLS works, according to . – Stefan Lasiewski Jan 26 at 22:00

A common cause of this problem is that the Common Name (CN) of the CA certificate is the same as the server and/or client certificate.

See here:

Try re-create your CA & certificate(s) and ensure to use of a unique CN in all cases.

share|improve this answer

I am running into a similiar issue with MacOS X client communicating with an Ubuntu server.

Can you check if the connection will work if you leave out the client side certificate and the client key, just having the CA for the server certificate? Are you able to establish an encrypted connection ? This will normally require the ANY setting for the associated user's ssl_type column.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.