Combining Root CA, Client Certificate and Private Key into a Single File

MySQL requires separate files for the client certificate, private key, and CA bundle to enforce mutual TLS correctly. Combining them into a single file often causes handshake failures because the server cannot distinguish between the identity credentials and the trust anchors. This guide details the proper file structure and configuration steps.

The Correct File Structure

To establish a secure connection using mutual TLS (mTLS), you must provide three distinct components. The server needs to verify the client's identity against its own certificate store, while the client needs to verify the server's identity against a trusted Certificate Authority. Mixing these roles in one file breaks the cryptographic chain of trust validation logic inherent in OpenSSL and MySQL's SSL implementation. You should maintain the following directory structure on your client machine:

• client-cert.pem: Your specific client certificate issued by the CA.
• client-key.pem: The private key corresponding to client-cert.pem. This file must be protected with strict permissions (chmod 600).
• ca-bundle.pem: The Root CA certificate or a concatenated file of all intermediate and root CAs that signed the server certificate.

This separation ensures that when the MySQL client initiates a connection, it presents its unique identity (cert and key) while trusting the authority defined in ca-bundle. If you combine the client key with the CA, the client might attempt to use the CA's private key for authentication, which is either impossible if you do not possess it, or a severe security vulnerability if you do.

Generating and Preparing the Certificates

Before configuring MySQL, ensure your certificates are generated correctly. You typically need a Certificate Authority (CA) to sign both the server and client certificates. If you are using a commercial CA, you will receive these files directly. If you are using self-signed certificates for development or internal networks, you can generate them using OpenSSL. First, generate the CA private key and certificate:

openssl genrsa -out ca-key.pem 2048
openssl req -new -x509 -key ca-key.pem -out ca-cert.pem -days 3650

Next, generate the client key and certificate request:

openssl genrsa -out client-key.pem 2048
openssl req -new -key client-key.pem -out client-req.pem
openssl x509 -req -in client-req.pem -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial -out client-cert.pem -days 3650

Verify that client-cert.pem was indeed signed by ca-cert.pem using the following command:

openssl verify -CAfile ca-cert.pem client-cert.pem

If this returns "OK", your certificate chain is valid. Do not concatenate client-key.pem into client-cert.pem or ca-cert.pem. Keep them as separate files.

Configuring the MySQL Client

When connecting to the MySQL server, you must specify the paths to these three separate files. You can do this via the command line, a configuration file, or your application's connection string. Using the command line interface, the syntax is:

mysql --ssl-ca=ca-bundle.pem --ssl-cert=client-cert.pem --ssl-key=client-key.pem -u username -p

If you prefer using a configuration file such as ~/.my.cnf, add the following section under [client]:

[client]
ssl-ca=/path/to/ca-bundle.pem
ssl-cert=/path/to/client-cert.pem
ssl-key=/path/to/client-key.pem

Ensure that the file permissions on client-key.pem are set to 600 so that only the owner can read it. MySQL may refuse to start or connect if the private key file is readable by other users, citing a security risk. For applications connecting via libraries like JDBC, ODBC, or Python's mysql-connector, you must map these parameters accordingly. For example, in a JDBC URL, you would include:

jdbc:mysql://host:3306/db?ssl=true&sslCaLocation=/path/to/ca-bundle.pem&sslCertLocation=/path/to/client-cert.pem&sslKeyLocation=/path/to/client-key.pem

Always test the connection after configuration. A successful connection indicates that the client successfully authenticated using the provided certificate and verified the server's certificate against the CA bundle.

Troubleshooting Common Errors

If you encounter errors during connection, check the following common issues: 1. Certificate Mismatch: Ensure that the client-cert.pem matches the client-key.pem. You can check the modulus of both files:

openssl x509 -noout -modulus -in client-cert.pem | openssl md5
   openssl rsa -noout -modulus -in client-key.pem | openssl md5

These hashes must be identical. 2. Expired Certificates: Verify that neither the client certificate nor the CA certificate has expired. Use openssl x509 -enddate -noout -in client-cert.pem to check the expiration date. 3. Permission Denied: If MySQL reports permission issues, run chmod 600 client-key.pem. On Windows, ensure the user account running the MySQL client has read access to the certificate files. 4. Server Configuration: Remember that the server also needs its own certificate and key configured. If the server is not properly configured to request client certificates, the client's presentation of a certificate may be ignored or cause a handshake failure depending on the require_secure_transport setting. By maintaining separate files for the CA, client certificate, and private key, you adhere to standard TLS practices and ensure reliable connectivity with MySQL servers. This approach avoids the pitfalls of bundle confusion and provides a clear audit trail for each component of the secure channel. For more information on ensuring your MySQL service remains stable and secure, consider reviewing how to manage service startup and security updates. See Ensuring MySQL Service Starts with systemd and Long Homebrew MySQL @ 8.0 Gets Security Updates for related operational guidance.

Frequently Asked Questions

Can I combine the client cert and key into one PEM file?

Yes, you can combine the client certificate and private key into a single PEM file, but you must keep the CA bundle separate. Many tools accept a combined cert+key file for the --ssl-cert parameter, but the --ssl-ca must still point to the CA certificate file alone. Never mix the CA certificate into the client credential file.

Why does MySQL reject my combined file with an unsupported key error?

MySQL expects the --ssl-cert parameter to contain the client's public certificate and optionally its private key, but not the CA's certificate. If you include the CA certificate in the same file, the parser may fail to identify the correct certificate type for authentication. Splitting the files resolves this parsing ambiguity.

How do I verify the server's certificate against my CA bundle?

You can verify the server's certificate manually using OpenSSL before connecting. Run openssl s_client -connect host:port -CAfile ca-bundle.pem. If the verification returns "verify return code: 0 (ok)", your CA bundle correctly trusts the server's certificate. This step helps isolate whether connection issues are due to client credentials or server trust.

Is it safe to share the CA bundle file?

Yes, the CA bundle contains only public certificates and can be shared freely. It is used to verify the identity of the server, not to authenticate the client. Unlike the private key, which must remain secret, the CA certificate is part of the public trust infrastructure and poses no security risk if exposed.

What happens if I use the wrong CA bundle?

If you use an incorrect CA bundle, the client will fail to verify the server's certificate, resulting in a "certificate verify failed" error. This prevents man-in-the-middle attacks by ensuring you are connecting to the intended server. Always ensure the CA bundle matches the issuer of the server's certificate.