Authorizing with SSL/TLS certificates

This page describes how Cloud SQL uses self-managed SSL/TLS certificates to securely connect to Cloud SQL instances.


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, use SSL/TLS certificates, so 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 PostgreSQL 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 will 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 a new server certificate has been added to the project. The existing server certificate, as well as any client certificates, continue 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 PostgreSQL clients to use the new file, by copying it to all of your PostgreSQL client host machines, replacing the existing file.

After all of your PostgreSQL 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.

Enforcing SSL/TLS encryption

Setting up your Cloud SQL instance to accept SSL/TLS connections enables SSL/TLS connections for the instance, but unsecure connections are still accepted. If you do not enforce SSL/TLS for all connections, any issue with your SSL/TLS configuration can cause all connections to default silently to unencrypted. If you do not require SSL/TLS for all connections, clients without a valid certificate are allowed to connect. For this reason, if you are accessing your instance using public IP, it is strongly recommended that you enforce SSL for all connections.

Authentication using authorized networks

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

In this case, PostgreSQL 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: or

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

  • Learn more about how PostgreSQL uses SSL/TLS.