This page describes how you can useSecure Socket Layer (SSL), nowTransport Layer Security (TLS), from your application to encryptconnections to Cloud SQL instances.

Overview

Cloud SQL supports connecting to an instance using the SSL/TLSprotocol. SSL/TLS connections provide a layer ofsecurity by encrypting data-in-transit between your client and the database inyour Cloud SQL instance. Optionally, your SSL/TLS connection canperform server identity verification by validating the server certificateinstalled on the Cloud SQL instance and client identity verificationby validating the client certificate installed on the client.

Server certificates

When you create an instance, Cloud SQL automatically creates andinstalls 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 toverify the CA and server Cloud SQL identity.Optionally, you can choose the type of CA that Cloud SQL uses to signthe server certificate.

Client certificates

You can optionally create and download client certificatesalong with keys to the client's host machine for mutual authentication(server and client identity verification). You can't choose the type of CAthat 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/TLSfor direct connections as well as for connections that useCloud SQL Auth ProxyorCloud SQL Language Connectors.

• For direct connections, Google strongly recommends enforcing SSL/TLS encryptionusing the SSL mode setting in Cloud SQL. Optionally, you canalso enforce client certificate verification. For more information, seeEnforce SSL/TLS encryption.

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

For more information about Cloud SQL connectivity options,seeAbout Cloud SQL connections.

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

Certificate authority (CA) hierarchies

This section describes the three types of server certificate authority (CA)that you can choose for your Cloud SQL instances. You have three 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, selectGoogle managed internal certificate authority (Google Cloud console) or specifyGOOGLE_MANAGED_INTERNAL_CA for theserverCaMode setting (Cloud SQL Admin API) or the--server-ca-mode flag (gcloud CLI) when youcreate the instance. If you leave the setting or flag unspecified when you create an instance, 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 handles the rotation of root CA and subordinate server CAs and provides publicly available links to theCA certificate bundles for download. To choose shared CA, specifyGOOGLE_MANAGED_CAS_CA for theserverCaMode setting (Cloud SQL Admin API) or the--server-ca-mode flag (gcloud CLI) when youcreate the instance.

• Customer-managed CA: with this option, youcreate and manage your own CA hierarchy. Choose this option if you want to manage your own CAs and certificates. To choose customer-managed CA, you need to create a CA pool and CA in CA Service. In Cloud SQL, specify the CA pool andCUSTOMER_MANAGED_CAS_CA for theserverCaMode setting (Cloud SQL Admin API) or the--server-ca-mode flag (gcloud CLI) when youcreate the instance.

  Note: You can configure the customer-managed CA option using thegcloud CLI, Cloud SQL Admin API, or Terraform, but you can't configure it using the Google Cloud console. If you select the customer-managed CA option, then the option appears selected in Google Cloud console.

After you create an instance, you can view which CA hierarchy is configured fora Cloud SQL instance by using thegcloud sql instances describe commandor in the Google Cloud console.For more information, seeView instance information.

Note: You can't modify the server CA mode instance setting for an instance after creation.

The following table compares the three CA hierarchyoptions.

Feature	Per-instance CA	Shared CA	Customer-managed CA
CA structure	Separate CA for each instance	Root CA and subordinate CAs shared across instances in the same region	CA hierarchy that you create and manage
Cryptographic attributes	RSA 2048-bit key with SHA256 algorithm	Elliptic Curve Digital Signature Algorithm (ECDSA) with 384-bit key with SHA384 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	Configurable *
Server certificate validity period	10 years	1 year	1 year**
User-initiated rotation of CA?	Yes	No. CA rotation is managed by Cloud SQL	Yes
User-initiated rotation of server certificate?	Yes	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.	The CAs that you create and manage are the trust anchors.
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.	Although the CA might not be shared across instances, you might want to verify the hostname along with verifying the CA.
Subject Alternative Name (SAN) field in server certificates	The SAN field contains the hostname (DNS name of the instance) only for instances enabled withPrivate 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) forall 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.	The SAN field contains the hostname (DNS name of the instance) forall types of instances. Hostname can be used for server identity verification.
Cloud SQL Auth Proxy version support	Supports all versions of the Cloud SQL Auth Proxy, v1 and later.	Requires the Cloud SQL Auth Proxy version 2.13.0 or later.	Requires the Cloud SQL Auth Proxy version 2.14.3 or later.
Service connection limitations	None	Doesn't support connections from the following Google Cloud services: App Engine standard environment App Engine flexible environment Cloud Run services that run in afirst generation execution environment	Doesn't support connections from the following Google Cloud services: App Engine standard environment App Engine flexible environment Cloud Run services that run in a first generation execution environment

* For the customer-managed CA option, the default validity period of a CA certificate in CA Service is 10 years. You have the option to configure a different validity period for your CA certificates. A shorter validity period for the CA might require more frequent CA rotations and a validity period shorter than one year might affect the validity period of your server certificates. For more information, seeManaging CA rotation.

** For the customer-managed CA option, the default validity period of a server certificate is one year. However, if you configure a validity period that is shorter than one year for your CA certificate, then your server certificate has a shorter validity period. For more information about configuring the validity period of your CA certificate upon creation, seeCA certificate settings andCreate a root CA.

Per-instance CA hosted by Cloud SQL

The per-instance CA hierarchy is the default server CA mode configuration when youcreate an instance using thegcloud CLI, Cloud SQL Admin API, or Terraform.

Cloud SQL creates a new self-signed server CA for eachinstance when you create the instance.To use this setting,configureserverCaMode toGOOGLE_MANAGED_INTERNAL_CA when you create the instance.You can either leave theserverCaModeconfiguration setting unspecified using Cloud SQL Admin API orgcloud CLI,or select theGoogle internal Certificate Authority option inthe Google Cloud console.

The following diagram shows the per-instance CA hierarchy.

Shared CAs hosted by CA Service

The shared CA hierarchy is the default server CA mode configuration when you createan instance using the Google Cloud console.

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

You can configure an instance to use a server CA hierarchy where the issuingCAs are shared across the instances in the same region. To use this setting,configureserverCaMode toGOOGLE_MANAGED_CAS_CA when you create the instance.You can also selectGoogle Managed CAS Certificate Authority in the Google Cloud console.

The following diagram shows the shared CA hierarchy.

Customer-managed CAs

This server CA mode lets you set up your own CA hierarchy inCA Service.

To use the customer-managed CA optionin Cloud SQL, you create a CA pool in the same regionas your Cloud SQL instances. Then you create at least one CA.When you create the Cloud SQL instance, specify the ID of theCA pool in theserverCaPool field and configure theserverCaMode fieldwith theCUSTOMER_MANAGED_CAS_CA value.CA Service provides a CA from the CA pool anduses that CA to issue the server certificate for the instance.

When you create CAs in CA Service, you can createeither a root CA or a subordinate CA depending on your use case.For example, you might want to create a subordinate CA if you plan toset up a root CA hierarchy or chain up to an external CA.

Select the customer-managed CA optiononly if you want to manage your own CAs and certificates. For more information,seeUse a customer-managed CA.

How server certificate rotation works

Cloud SQL provides ways torotate your server certificate,so the new certificate can be seamlessly swapped in before the old certificateexpires.

For instances that use the per-instance CA, shared CA, or customer-managed CA hierarchies, aboutthree months before the server certificate expires for a Cloud SQLinstance, the project owners receive an email from Cloud SQL, statingthat the certificate rotation process has begun for that instance.The email provides the name of the instance, and says that Cloud SQLhas added a new server certificate to the project. The existing server certificatecontinues to function normally. In effect, theinstance has two server certificates during this period.

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

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

After all of your PostgreSQL clients have been updated, send arotate command (for per-instance CA) orrotate command (for shared CA or customer-managed CA)to the Cloud SQLinstance to rotate to the new server certificate. After that is done, theold server certificate is no longer recognized, and only the new servercertificate can be used.

Client certificates are not affected by server certificate rotation.

SSL certificate expiration

For Cloud SQL instances that use per-instance CAs(serverCaMode is set toGOOGLE_MANAGED_INTERNAL_CA),the SSL certificates come with anexpiration period of 10 years. Before these certificatesexpire, performserver CA certificate rotation.

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

If you're using a customer-managed CA (serverCaMode is set toCUSTOMER_MANAGED_CAS_CA),then you can perform CA certificate rotation by rotating the CAs in theCA pool that you created. The expiration period of a CA is typically 10 years,but you can configure a shorter validity period for your CA in CA Service.

To rotate the CAs, use the CA rotation process in CA Service.For more information, seeManaging CA rotation.

If a client is configured to verify the CA or verify the hostname in the servercertificate, then that client's connections to Cloud SQL instances withexpired 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, the shared CA, or the customer-managed CAserver mode, you canreset the SSLconfiguration of your Cloud SQL instance at any time.

What's next

• Configure SSL/TLS on yourCloud SQL instance.

• Learn more abouthow encryption is handled in Google Cloud.

• Connect using SSL/TLSto your Cloud SQL instance.

• Manage SSL/TLS on your Cloud SQL instance.

• Learn more abouthow PostgreSQL uses SSL/TLS.