SSL certificates overview

Transport Layer Security (TLS) is an encryption protocol used in SSL certificates to protect network communications.

Google Cloud uses SSL certificates to provide privacy and security from a client to a load balancer. To achieve this, the load balancer must have an SSL certificate and the certificate's corresponding private key. Communication between the client and the load balancer remains private—illegible to any third party that doesn't have this private key.

Load balancers

The following table summarizes the types of Google Cloud load balancers that require SSL certificates.

Load balancer type Protocol from the client to the load balancer
Internal HTTPS load balancers HTTPS or HTTP/2
External HTTPS load balancers HTTPS or HTTP/2
SSL proxy load balancers SSL (TLS)

Self-managed and Google-managed SSL certificates

You can obtain your own self-managed certificates or you can use Google-managed certificates, which Google obtains and manages for you.

  • Self-managed SSL certificates are certificates that you obtain, provision, and renew yourself. This type can be any of:

    • Domain Validation (DV)
    • Organization Validation (OV)
    • Extended Validation (EV) certificates

    For more information, see Public key certificate.

  • Google-managed SSL certificates are certificates that Google Cloud obtains and manages for your domains, renewing them automatically. Google-managed certificates are Domain Validation (DV) certificates. They don't demonstrate the identity of an organization or individual associated with the certificate, and they don't support wildcard common names.

For external HTTP(S) load balancer and SSL proxy load balancer, you can reference either Google-managed, self-managed, or a combination of both types of SSL certificates on one target proxy. The certificates can be referenced in any order. For internal HTTP(S) load balancer, you must use self-managed certificates.

For information about configuring SSL certificates for your load balancers, see the following guides:

Multiple SSL certificates

You can configure up to the maximum number of SSL certificates per target HTTPS or target SSL proxy. Use multiple SSL certificates when you are serving from multiple domains using the same load balancer IP address and port, and you want to use a different SSL certificate for each domain.

When you specify more than one SSL certificate, the first certificate in the list of SSL certificates is considered the primary SSL certificate associated with the target proxy.

When a client sends a request, the load balancer uses the SNI hostname specified by the client to select the certificate to use in negotiating the SSL connection.

Whenever possible, the load balancer selects a certificate whose common name (CN) or subject alternative name (SAN) matches the SNI hostname that is specified by the client. RSA and ECDSA are types of digital signatures, and the client software must be able to use them.

If none of the available certificates can be selected, or if the client doesn't specify an SNI hostname, the load balancer negotiates SSL using the primary certificate (the first certificate in the list).

Multiple SSL certificates (click to enlarge)
Multiple SSL certificates (click to enlarge)

Encryption from the load balancer to the backends

For HTTP(S) Load Balancing, TCP Proxy Load Balancing, and SSL Proxy Load Balancing, Google automatically encrypts traffic between Google Front Ends (GFEs) and your backends that reside within Google Cloud.

In addition to this network-level encryption, you can use a secure protocol as the backend service protocol. Secure protocols include SSL, HTTPS, or HTTP/2 (using TLS). You can use them for the GFE-based load balancers, and for Internal HTTP(S) Load Balancing and Traffic Director.

When a load balancer connects to your backends using a secure backend service protocol, the GFE is the SSL or HTTPS client. Similarly, when a client-side proxy configured using Traffic Director connects to your backends using a secure backend service protocol, the proxy is the SSL or HTTPS client.

A secure protocol to connect to backend instances is recommended in the following cases:

  • When you require an auditable, encrypted connection from the load balancer (or Traffic Director) to the backend instances.

  • When the load balancer connects to a backend instance that is outside of Google Cloud (via an internet NEG). Communication to an internet NEG backend might transit the public internet. When the load balancer connects to an internet NEG, the public CA-signed certificate must meet the validation requirements.

To use a secure protocol between the load balancer and your backends, keep the following requirements in mind:

  • Your load balancer's backend services must use the SSL (TLS), HTTPS, or HTTP/2 protocol.

  • Backend instance software must serve traffic using the same protocol as the backend service. For example, if the backend service uses HTTPS, make sure to configure your backend instances to use HTTPS. If you use the HTTP/2 protocol, your backends must use TLS. For configuration instructions, refer to your backend instance's software documentation.

  • You must install private keys and certificates on your backend instances. These certificates don't need to match the load balancer's SSL certificate. For installation instructions, refer to your backend instance's software documentation.

  • The software running on your backend instances must operate as an SSL or HTTPS server. For configuration instructions, refer to your backend instance's software documentation.

Keep the following in mind when using instance group or zonal NEG backends:

  • When a GFE starts a TLS session to backends, the GFE doesn't use the Server Name Indication (SNI) extension.

  • When a GFE connects to backends that are within Google Cloud, the GFE accepts any certificate your backends present. GFEs do not perform certificate validation. For example, the certificate is treated as valid even in the following circumstances:

    • The certificate is self-signed.
    • The certificate is signed by an unknown certificate authority (CA).
    • The certificate has expired or is not yet valid.
    • The CN and subjectAlternativeName attributes don't match a Host header or DNS PTR record.
For additional information on Google's encryption, see Encryption in Transit in Google Cloud.

Load balancers, SSL certificates, and target proxies

A Google Cloud SSL certificate resource contains both a private key and the SSL certificate itself.

Target proxies represent the logical connection between a load balancer's frontend and its backend service (for SSL proxy load balancers) or URL map (for HTTPS load balancers).

The following diagram shows how the target proxy and its associated SSL certificates fit into the load balancing architecture.

Target proxy, SSL certificate, and other load balancer components (click to enlarge)
Target proxy, SSL certificate, and other load balancer components (click to enlarge)

SSL certificate scope

Google Cloud has two scopes for SSL certificate resources, regional and global.

Load balancer type Scope of SSL certificate resource gcloud reference API reference
Internal HTTPS load balancers Regional gcloud compute ssl-certificates --region regionSslCertificates
External HTTPS load balancers Global gcloud compute ssl-certificates --global sslCertificates
SSL proxy load balancers Global gcloud compute ssl-certificates --global sslCertificates

Target proxies

SSL certificates are associated with the following types of target proxies:

Load balancer type Type of target proxy gcloud reference API reference
Internal HTTPS load balancers Regional gcloud compute target-https-proxies --region regionTargetHttpsProxies
External HTTPS load balancers Global gcloud compute target-https-proxies --global targetHttpsProxies
SSL proxy load balancers Global gcloud compute target-ssl-proxies --global targetSslProxies

Limitations

  • A limited number of SSL certificates is supported for each target proxy. For more information, see the limit for SSL certificates per target HTTPS or target SSL proxy.

  • A limited number of domains is supported for each Google-managed certificate. For more information, see the limit for domains per Google-managed SSL certificate.

  • When you use Google-managed certificates with SSL Proxy Load Balancing, the load balancer's forwarding rule must use TCP port 443 for the Google-managed certificate to be renewed automatically.

  • Google Cloud load balancers don't support client certificate-based authentication (mutual TLS, mTLS).

  • Google-managed SSL certificates don't support using wildcards.

What's next