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 theserverCaMode
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 theserverCaMode
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.
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.
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 MySQL clients to use the new
file, by copying it to all of your MySQL client host machines, replacing
the existing file.
After all of your MySQL 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
Configure SSL/TLS on your Cloud SQL instance.
Learn more about how encryption is handled in Google Cloud.
- Connect using SSL/TLS to your Cloud SQL instance.
- Manage SSL/TLS on your Cloud SQL instance.
- Learn more about how MySQL uses SSL/TLS.