MySQL Bugs: #68052: SSL Certificate Subject ALT Names with IPs not respected with --ssl-verify-serve

Bug #68052	SSL Certificate Subject ALT Names with IPs not respected with --ssl-verify-serve
Submitted:	8 Jan 2013 19:50	Modified:	4 Jun 2018 15:06
Reporter:	Ryan Lowe	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: C API (client library)	Severity:	S3 (Non-critical)
Version:	5.5.29, 5.7.1	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	SSL

Description:
When connecting to a host with --ssl-verify-server-cert, it does not inspect subject alt names.

ERROR 2026 (HY000): SSL connection error: SSL certificate validation failure

Refer to http://www.openssl.org/docs/apps/x509v3_config.html#Subject_Alternative_Name_

How to repeat:
(create and set up valid certificates with subject )

connect to the hostname (that is in the CN) -- Success
connect to the IP (that is in the subject alt name) -- Failure

Suggested fix:
Look at subject alt names in addition to the CN.

Thank you for the report.

Verified as described.

Since mysql community builds use embedded yassl rather than link against openssl,unless yassl strictly adheres to openssl specifications, it may not work.

Tested with 5.7.10. The Subject Alternative Name (aka subjectAltName, aka SAN) is ignored. This happens with a YaSSL server/client and with an OpenSSL server/client.

This severely limits the usefulness of the --ssl-verify-server-cert option.

In a standard replication setup (1 master with 2 slaves which have 10 slaves each) this should work because slaves connect to the real hostname of its master. This hostname is expected to be in the CommonName (CN) of the certificate. 'CHANGE MASTER TO MASTER_SSL_VERIFY_SERVER_CERT=1' together with the normal TLS/SSL settings should work fine.

But read/write connections to the master might go to a CNAME which points to the active master or to a floating IP (aka VIP) which is active on the server which has the role of the primary master. Another posibility is to have a TCP loadbalancer like HAProxy. The DNS name for the CNAME, VIP or loadbalancer in this case doesn't match the CN of the server certificate. Enabling verification won't work.

For HTTP(S) the TLS connection can be terminated on the loadbalancer, which should have a certificate with the correct hostname in the certificate. Then the loadbalancer connects to the backend server using TLS on the hostname of the server. This could also work for MySQL, but there is a big limitation:
I don't know if any loadbalancers support the MySQL protocol. This is needed because every connection starts unencrypted and then switches to encrypted. This is similar to STARTTLS in email protocols. The full-TLS property of HTTPS makes this much easier to support on a loadbalancer.

Clustered setups with a cold standby (Pacemaker etc.) often use a virtual IP for the slaves to connect to. This would work if the vIP hostname/IP is the CN, but then management traffic can't use hostname verification. This might be needed for monitoring a specific host or using a tool like MySQL Workbench to connect to a specific host to manage it. Note that this probably won't affect MySQL Enterprise Monitor and tools which use an agent and/or localhost connections. But MEM in agentless mode might not be able to use hostname verification.

The current version of mysql_ssl_rsa_setup uses 'CN=MySQL_Server_5.7.10_Auto_Generated_Server_Certificate' instead of a hostname.
Eventually it might be better to change this to keep this CN but include the hostnames of the machine as a Subject Alternative Name. Note that this is not enough to enable hostname verification as each server has it's own CA. The client should collect all CA certificates of the servers it wants to connect to. But for (very)small setups this might be ok.

If Subject Alternative Names are not used at all, even for domain names, please update the bug title to reflect that.

https://tools.ietf.org/html/rfc6125#section-6.4.4 has some more info on this topic.

Not that they are the single authority, but DigiCert has a nice note on SAN and CN: https://www.digicert.com/subject-alternative-name-compatibility.htm

If a SSL Certificate has a Subject Alternative Name (SAN) field, then SSL clients are supposed to ignore the Common Name value and seek a match in the SAN list. This is why DigiCert always repeats the common name as the first SAN in our certificates.

I had a quick look at this bug:
https://github.com/mysql/mysql-server/pull/196

Bug #89578 	Contribution: Use native host check from OpenSSL

Posted by developer:
 
Fixed in 5.6.41, 5.7.23.

Previously, for the --ssl-mode=VERIFY_IDENTITY or
--ssl-verify-server-cert option, the client checked the Common Name
value in the certificate but not the Subject Alternative Name value.
Now, if MySQL was built using OpenSSL 1.0.2 or higher, the client
checks whether the host name that it uses for connecting matches the
Subject Alternative Name value or the Common Name value in the server
certificate.