Authorize with SSL/TLS certificates

This page describes how Cloud SQL uses self-managed Secure Socket Layer (SSL)/Transport Layer Security(TLS) certificates to securely connect to Cloud SQL instances.

Overview

Cloud SQL supports connecting to an instance using the Transport Layer Security (SSL/TLS) protocol. Data in transit inside a physical boundary controlled by or on behalf of Google is generally authenticated but might not be encrypted by default. If you connect to an instance using its public IP address, you must enforce SSL/TLS certificates so that the data is secure during transmission. SSL/TLS is the standard protocol for encryption of data sent over the internet. If your data isn't encrypted, anyone can examine your packets and read confidential information.

The safest method of encryption is called asymmetrical cryptography; this requires two cryptographic keys, one public and one private. Essentially, you use the public key to encrypt the data, and use the private key to decrypt it. Both the server and the client machines have the same set of client keys.

In Cloud SQL, the public key is named client-cert.pem and the private key is named client-key.pem. The server also generates its own certificate, called server-ca.pem.

Your application requires all three keys to connect successfully. Store these keys securely; anyone with access to these keys could potentially connect or intercept your data. You can't retrieve the private key from the server later, so if you lose it, you need to create new client certificates to replace the ones previously in use. Likewise, when the server generates a new server-ca.pem file, you need to download it and store it on the MySQL client's host machine, replacing the existing file.

SSL/TLS certificates

A server Certificate Authority (CA) certificate is required in SSL connections. Cloud SQL creates a server certificate automatically when you create your instance. As long as the server certificate is valid, you do not need to actively manage your server certificate. However, the certificate has an expiration date of 10 years; after that date, it is no longer valid, and clients are not able to establish a secure connection to your instance using that certificate. You can also manually create a new one.

You create client certificates yourself. There is a limit of 10 client certificates per Cloud SQL instance.

How server certificate rotation works

Cloud SQL provides a way to rotate your server certificate, so a new certificate can be seamlessly swapped in before the old certificate expires.

About three months before the server certificate expires for a Cloud SQL instance, the project owners receive an email from Cloud SQL, stating that the certificate rotation process has begun for that instance. The email provides the name of the instance, and says that Cloud SQL has added a new server certificate to the project. The existing server certificate continues to function normally. In effect, the instance has two server certificates during this period.

Before the current certificate expires, download the new server-ca.pem file, which contains the certificate information for both the current and the new server certificates. Update your MySQL clients to use the new file, by copying it to all of your MySQL client host machines, replacing the existing file.

After all of your MySQL clients have been updated, send a command to the Cloud SQL instance to rotate to the new server certificate. Once that is done, the old server certificate is no longer recognized, and only the new server certificate can be used.

Client certificates are not affected by server certificate rotation.

Enforce SSL/TLS encryption

Configuring your Cloud SQL instance to accept SSL/TLS connections enables SSL/TLS connections for the instance, but unencrypted and unsecure connections are still accepted. If you do not require SSL/TLS for all connections, unencrypted connections are still allowed. For this reason, if you are accessing your instance using public IP, it is strongly recommended that you enforce SSL for all connections.

Per account user settings can override the global setting enabled or disabled by enforcing SSL. The SSL status of a user account is indicated in the ssl_type column of the mysql.user table. For more information, see Configuring MySQL to use encrypted connections.

Use authorized networks

If your Cloud SQL instance is using a public IP address, you need to add the IP addresses of your MySQL clients as authorized networks when configuring SSL/TLS.

In this case, MySQL clients are only authorized to connect if their IP addresses are added to this list. The IP addresses can limited to a single endpoint or consist of a range in CIDR format. For example: 10.50.51.3 or 10.50.51.0/26.

SSL certificate expiry

SSL certificates associated with Cloud SQL instances come with an expiry period of 10 years. On expiry, perform SSL certificate rotation. You can also reset the SSL configuration of your Cloud SQL instance at any time.

What's next