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.

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 256-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 SQL Server clients to use the new file, by copying it to all of your SQL Server client host machines, replacing the existing file.

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

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