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,
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.
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
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.
Using authorized networks
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:
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.
- Configure SSL/TLS on your Cloud SQL instance.
- Connect using SSL/TLS to your Cloud SQL instance.
- Manage SSL/TLS on your Cloud SQL instance.
Learn more about how PostgreSQL uses SSL/TLS.