Multiple certificates in keystore for Mysql SSL Client authentication and JMX over SSL setup

Question

My Java application needs to authenticate to Google cloud Mysql instance with SSL client authentication. Its client-key and certificate are provided by Google. I also need to setup JMX agent with SSL on same application whose certificates are provided by a private CA.

How to prevent Mysql from presenting JMX certificate and vice-versa in case I add both private certificates into single keystore provided to JVM at startup

Is there any other way to authenticate SSL certificates with Mysql beside putting then in 'javax.net.ssl.keyStore'? If not, are there any aliases that Mysql or JMX agent prefer over other names?

Bakehouse

As far as I know, you should not have to handle that situation yourself. The keystore will offer all certificates, and the SSL negotiation should sort out which one "matches" – Cleanthes

Answer 1

You can look at using the Cloud SQL MySQL socket factory which uses temporary SSL certificates to authenticate to Cloud SQL (only supported for Second Generation instances):

https://github.com/GoogleCloudPlatform/cloud-sql-mysql-socket-factory

Sambo

Well, this solves the OP's problem because they happen to use CloudSQL from Google. However, it doesn't really solve the question itself, with regards to allowing the use of multiple certs in the same app. – Defame

Looking at the driver internals, there are some properties for specifying the keystore. They don't seem to be documented anywhere... I found a blog post that lists them. Assuming that they work as intented, it should be possible to specify a separate keystore for mysql connections. Unfortunately I don't have time to test whether that actually works. – Sambo

@Sambo It works. You can edit your answer to put those variables here. – Bakehouse

Answer 2

This is an almost 10-year-old question, but since there's no accepted answer I'd like to provide one.

Since you are also using java and what I assume to be mysql jdbc connector, if you have separate keystores (one for your JMX agent and one for Google Cloud Mysql server), you can let the JMX keystore use the default keystore settings via the java args (-Djavax.net.ssl.keyStore, -Djavax.net.ssl.keyStoreType, -Djavax.net.ssl.keyStorePassword).

The Google Cloud Mysql server's keystore/truststore settings can then be configured in the jdbcurl connection string as such.

jdbc:mysql://your_mysql_server:3306/db_name?sslMode=REQUIRED&trustCertificateKeyStoreUrl=file:/path/to/your/truststore.jks&trustCertificateKeyStoreType=JKS&trustCertificateKeyStorePassword=changit&clientCertificateKeyStoreUrl=file:/path/to/your/keystore.jks&clientCertificateKeyStoreType=JKS&clientCertificateKeyStorePassword=changeit&enabledTLSProtocols=TLSv1.2

mysql-connector will prioritize the keystore/truststore specified in the jdbc url over the default -Djavax ones, so this would allow you to use each keystore/truststore separately.

You can learn more about the parameters in the above jdbcurl connection string as well as others via section 6.3 Configuration Properties of the official mysql-connector/J documentation. The section regarding SSL/TLS related parameters is under 6.3.5 Security

Hammon

Answer 3

MySQL Connecting Securely Using SSL

For SSL support to work, you must have the following:

1. A JDK that includes JSSE (Java Secure Sockets Extension), like JDK-1.4.1 or newer. SSL does not currently work with a JDK that you can add JSSE to, like JDK-1.2.x or JDK-1.3.x due to the following JSSE bug: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4273544

2. A MySQL server that supports SSL and has been compiled and configured to do so, which is MySQL 4.0.4 or later. For more information, see Building MySQL with Support for Secure Connections.

A client certificate (covered in this section)

---

How to work with multiple keystore?

The test certificates reside in keystores named node1.keystore … node100.keystore, which were created following the steps described in Creating Self-Signed Test Certificates.

1. Export the test certificate for node1.example.com:

   $ keytool -exportcert -keystore node1.keystore -alias node1 \
   -storepass changeme -file node1.cer
   

2. Import the test certificate into the custom truststore:

   keytool -importcert -keystore custom.truststore -alias node1 \
   -storepass trustchangeme -file node1.cer -noprompt
   

   Here we specify the -noprompt option to suppress the prompt asking you to confirm that the certificate is trustworthy. Since you created the certificate yourself, this confirmation is unnecessary.

3. Repeat Steps 1 and 2 for node2.keystore … node100.keystore.

Resource Link:

1. Creating Java Keystores and Truststores

---

Keystore and truststore details:

A keystore is used in one of two distinct ways:

1. The keystore contains private keys and certificates used by TLS/SSL servers to authenticate themselves to TLS/SSL clients. By convention, such files are referred to as keystores.
2. When used as a truststore, the file contains certificates of trusted TLS/SSL servers, or of Certificate Authorities trusted to identify servers. There are no private keys in the truststore.

Because keystores contain private keys, while truststores do not, the security requirements for keystores are more stringent. In particular:

1. Hadoop TLS/SSL requires that truststores and the truststore password be stored, in plaintext, in a configuration file that is readable by all.
2. Keystore and key passwords are stored, in plaintext, in a file that is readable only by members of the appropriate group.

These considerations should inform your choice of which keys and certificates to store in the keystores and truststores you will deploy across your cluster.

1. Keystores should contain a minimal set of keys and certificates. A reasonable strategy would be to create a unique keystore for each host, which would contain only the keys and certificates needed by the Hadoop TLS/SSL services running on the host. In most cases, the keystore would contain a single key/certificate entry.

2. Modifying Keystores: CDH services and processes must be restarted in case changes are made to a keystore. However, this is relatively rare since keystores do not need to be updated when hosts are added or deleted from a cluster.

3. Because truststores do not contain sensitive information, it is reasonable to create a single truststore for an entire cluster. On a production cluster, such a truststore would often contain a single CA certificate (or certificate chain), since you would typically choose to have all certificates issued by a single CA.

Important: Do not use the same password for truststores and keystores/keys.

Since truststore passwords are stored in the clear in files readable by all, doing so would compromise the security of the private keys in the keystore.

Rights

Really nice answer. I think "A client certificate" was meant to be a third number list item, right? – Larondalarosa

The question is asking how to use two different keystores within the same application. You do not address that. The concern here is that the OP needs to do X503 auth with a mysql database. That requires a specific certificate issues by the mysql vendor. On the other hand, they also need to make JMX available, on the same application, using a different certificate. setting the keystore in JAVA_OPTS forces both to use the same keystore. The question is "Can you set the keystore in some other way, or indicate the alias to use from the keystore, so that both keys can be used" – Defame