Authorize with SSL/TLS certificates

This page describes how you can use Secure Socket Layer (SSL), now Transport Layer Security (TLS), from your application to encrypt connections to Cloud SQL instances.

Overview

Cloud SQL supports connecting to an instance using the SSL/TLS protocol. SSL/TLS connections provide a layer of security by encrypting data-in-transit between your client and the database in your Cloud SQL instance. Optionally, your SSL/TLS connection can perform server identity verification by validating the server certificate installed on the Cloud SQL instance and client identity verification by validating the client certificate installed on the client.

Server certificates

When you create an instance, Cloud SQL automatically creates and installs a server certificate that is signed by a certificate authority (CA). You can download the CA certificate to the client host machine and use it to verify the CA and server Cloud SQL identity. Optionally, you can choose the type of CA that Cloud SQL uses to sign the server certificate.

Client certificates

You can optionally create and download client certificates along with keys to the client's host machine for mutual authentication (server and client identity verification). You can't choose the type of CA that Cloud SQL uses to sign the client certificate.

Connect using SSL/TLS

When connecting to a Cloud SQL instance from clients, you can use SSL/TLS for direct connections as well as for connections that use Cloud SQL Auth Proxy or Cloud SQL Language Connectors.

  • For direct connections, Google strongly recommends enforcing SSL/TLS encryption using the SSL mode setting in Cloud SQL. Optionally, you can also enforce client certificate verification. For more information, see Enforce SSL/TLS encryption.

  • For connections that use Cloud SQL Auth Proxy or Cloud SQL Language Connectors, the connections are automatically encrypted with SSL/TLS along with client and server identity verification without requiring you to download a server CA certificate and client certificate.

For more information about Cloud SQL connectivity options, see About Cloud SQL connections.

For more information about client-side SSL/TLS configuration, see the documentation for your database engine.

Certificate authority (CA) hierarchies

This section describes the two types of server certificate authority (CA) that you can choose for your Cloud SQL instances. You have two options:

  • Per-instance CA: with this option, an internal CA dedicated to each Cloud SQL instance signs the server certificate for that instance. Cloud SQL creates and manages these CAs. To choose per-instance CA, specify GOOGLE_MANAGED_INTERNAL_CA for the serverCaMode setting (Cloud SQL Admin API) or the --server-ca-mode flag (gcloud CLI) when you create the instance. If you leave the setting or flag unspecified, then this option is the default value for the instance.

  • Shared CA: with this option, a CA hierarchy consisting of a root CA and subordinate server CAs is used. The subordinate server CAs in a region sign the server certificates and are shared across instances in the region. Cloud SQL hosts and manages the root CA and subordinate server CAs on Google Cloud Certificate Authority Service (CA Service). Cloud SQL also also handles the rotation of root CA and subordinate server CAs and provides publicly available links to the CA certificate bundles for download. To choose shared CA, specify GOOGLE_MANAGED_CAS_CA for the serverCaMode setting (Cloud SQL Admin API) or the --server-ca-mode flag (gcloud CLI) when you create the instance.

After you create an instance, you can view which CA hierarchy is configured for a Cloud SQL instance by using the gcloud sql instances describe command. For more information, see View instance information.

The following table compares the two CA hierarchy options.

Feature Per-instance CA Shared CA
CA structure Separate CA for each instance Root CA and subordinate CAs shared across instances in the same region
Cryptographic attributes RSA 2048-bit key with SHA256 algorithm Elliptic Curve Digital Signature Algorithm (ECDSA) with 384-bit key with SHA384 algorithm
CA validity period 10 years 25 years for root CA and 10 years for subordinate CAs
Server certificate validity period 10 years 1 year
User-initiated rotation of CA? Yes No. CA rotation is managed by Cloud SQL
User-initiated rotation of server certificate? Yes Yes
CA trust anchor for TLS connections The unique per-instance CA is the trust anchor for the corresponding instance. Root CA and subordinate CAs are the trust anchors for all instances in a given region.
Server identity verification Verifying the CA verifies the server identity since each instance has a unique CA. Verifying the hostname along with verifying the CA is required for server identity verification since server CAs are shared across instances.
Subject Alternative Name (SAN) field in server certificates The SAN field contains the hostname (DNS name of the instance) only for instances enabled with Private Service Connect. Hostname can be used for server identity verification. If you are connecting to a Cloud SQL instance using the DNS name as the hostname, then you need to set up DNS resolution. The SAN field contains the hostname (DNS name of the instance) for all types of instances. Hostname can be used for server identity verification. If you are connecting to a Cloud SQL instance using the DNS name as the hostname, then you need to set up DNS resolution.

Per-instance CA hosted by Cloud SQL

This CA hierarchy is the default server CA mode configuration.

Cloud SQL creates a new self-signed server CA for each instance when you create the instance. To use this setting, configure serverCaMode to GOOGLE_MANAGED_INTERNAL_CA or leave the configuration setting unspecified when you create the instance.

The following diagram shows the per-instance CA hierarchy.

Diagram of per-instance internal CA hierarchy.

Shared CAs hosted by CA Service

This server CA mode consists of a root CA and subordinate server CAs in each region. The subordinate server CAs issue server certificates and are shared across instances in the region. Cloud SQL handles the rotation of the shared regional server CAs and provides publicly available links download the CA certificate bundles.

You can configure an instance to use a server CA hierarchy where the issuing CAs are shared across the instances in the same region. To use this setting, configure serverCaMode to GOOGLE_MANAGED_CAS_CA when you create the instance.

The following diagram shows the shared CA hierarchy.

Diagram of a shared CA hierarchy

How server certificate rotation works

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

The rotation command to use depends on whether you are using a server certificate issued by a per-instance CA or a server certificate issued by the shared CA.

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 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 rotate command (for per-instance CA) or rotate command (for shared CA) to the Cloud SQL instance to rotate to the new server certificate. After 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.

SSL certificate expiration

By default Cloud SQL instances use the default setting of GOOGLE_MANAGED_INTERNAL_CA as the serverCaMode. The SSL certificates come with an expiration period of 10 years. Before these certificates expire, perform CA rotation.

For instances that use shared CAs (serverCaMode is set to GOOGLE_MANAGED_CAS_CA), the expiration period of the server certificates is 1 year. Before expiration, perform SSL certificate rotation. The root certificate authority (CA) certificate has an expiration period of 25 years and the subordinate shared CA certificate has an expiration period of 10 years. Cloud SQL handles their rotation.

If a client is configured to verify the CA or verify the hostname in the server certificate, then that client's connections to Cloud SQL instances with expired server certificates will fail. To prevent disruption to client connections, rotate the server certificate before the certificate expires.

Whether you use the per-instance CA or the shared CA server mode, you can reset the SSL configuration of your Cloud SQL instance at any time.

What's next