SSL certificates overview

SSL/TLS is the most widely used cryptographic protocol on the internet. Technically, TLS is the successor to SSL, although the terms are sometimes used interchangeably, as they are in this document.

Transport Layer Security (TLS) is used to encrypt information while it is sent over a network, providing privacy between a client and a server or load balancer. An Application Load Balancer or proxy Network Load Balancer that uses SSL requires at least one private key and SSL certificate.

Certificate configuration methods

Google Cloud offers three certificate configuration methods for Application Load Balancers using target HTTPS proxies and proxy Network Load Balancers using target SSL proxies.

Target proxy references Compute Engine SSL certificates: with this method, the load balancer's target proxy can reference up to 15 Compute Engine SSL certificate resources. Each Compute Engine SSL certificate resource contains the private key, corresponding certificate, and—optionally—CA certificates.
Target proxy references a Certificate Manager certificate map: with this method, the load balancer's target proxy references a single certificate map. The certificate map supports thousands of entries by default, and can scale to millions of entries. Each entry contains private key and certificate data.
Target proxy references Certificate Manager certificates directly: with this method, the load balancer's target proxy can reference up to 100 Certificate Manager certificates.

Load balancer support

The following table shows which certificate configuration methods each load balancer supports.

Load balancer	Certificate configuration method: Target proxy references...
Load balancer	Compute Engine SSL certificates	A Certificate Manager certificate map	Certificate Manager certificates directly
Application Load Balancers (target HTTPS proxies)
Global external Application Load Balancer	Supports global certificates Self-managed Google-managed	Self-managed Google-managed
Classic Application Load Balancer	Supports global certificates Self-managed Google-managed	Self-managed Google-managed
Regional external Application Load Balancer	Supports regional certificates Self-managed Google-managed		Self-managed Google-managed
Regional internal Application Load Balancer	Supports regional certificates Self-managed Google-managed		Self-managed Google-managed
Cross-region internal Application Load Balancer			Self-managed Google-managed
Proxy Network Load Balancers (target SSL proxies)
Global external proxy Network Load Balancer	Supports global certificates Self-managed Google-managed	Self-managed Google-managed
Classic proxy Network Load Balancer	Supports global certificates Self-managed Google-managed	Self-managed Google-managed

Configuration method rules

Google Cloud enforces the following certificate configuration method rules:

For load balancers that support both Compute Engine SSL certificates and Certificate Manager certificate maps: the load balancer's target proxy can simultaneously reference both a certificate map and one or more Compute Engine SSL certificates; however, in such a case, all Compute Engine SSL certificates are ignored, and only the certificates from the certificate map are used by the load balancer.
For load balancers that support both Compute Engine SSL certificates and directly-attached Certificate Manager certificates: the load balancer's target proxy can only be configured to reference up to 15 Compute Engine SSL certificates or up to 100 Certificate Manager certificates, not a combination of both.

Certificate types

Google Cloud supports both self-managed and Google-managed certificates.

Self-managed SSL certificates

Self-managed SSL certificates are certificates that you obtain, provision, and renew yourself. Self-managed certificates can be any of these Public key certificate types:

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

You can create self-managed SSL certificates using:

Compute Engine SSL certificate resources: for more information, see Use self-managed SSL certificates.
Certificate Manager: for more information, see Deployment overview in the Certificate Manager documentation.

Google-managed SSL certificates

Google-managed SSL certificates are certificates that Google Cloud obtains, manages, and renews automatically. Google-managed certificates are always Domain Validation (DV) certificates. They don't demonstrate the identity of an organization or individual associated with the certificate.

Google-managed certificates using wildcards are only supported by Certificate Manager when using DNS authorization.

You can create Google-managed SSL certificates using:

Compute Engine SSL certificate resources: only global Compute Engine sslCertificates resources support Google-managed SSL certificates; regionSslCertificates don't support them. Global Compute Engine SSL certificates support only publicly trusted Google-managed certificates. For more information, see Use Google-managed SSL certificates.
Certificate Manager: Certificate Manager certificates (both global and regional) support both publicly trusted Google-managed certificates and privately trusted Google-managed certificates. For more information, see Certificates in the Certificate Manager documentation.

Supported key types

Load balancers support certificates that use private keys of different key types. The following table shows the key type support depending on whether the certificates are global or regional, and whether they are self-managed or Google managed.

SSL certificate type arrow_forward Key type arrow_downward	Compute Engine SSL certificates			Certificate Manager SSL certificates
	Global		Regional	Global and regional
	Self-managed	Publicly trusted Google-managed	Self-managed	Self-managed	Publicly trusted Google-managed	Privately trusted Google-managed
RSA-2048
RSA-3072
RSA-4096
ECDSA P-256
ECDSA P-384

To learn more about Certificate Manager certificates, see the Certificate Manager documentation.

Multiple SSL certificates

An Application Load Balancer or proxy Network Load Balancer can host two or more SSL certificates simultaneously when its target proxy is configured using a supported certificate configuration method. As a best practice, use Certificate Manager when multiple SSL certificates are needed.

For load balancers that support Compute Engine SSL certificates: the load balancer's target proxy can reference up to 15 Compute Engine SSL certificates. The first referenced Compute Engine SSL certificate resource is the default (primary) certificate for the target proxy.
For load balancers that support a Certificate Manager certificate map: the load balancer's target proxy references a single certificate map. The certificate map supports thousands of certificate map entries. You can configure which certificate entry is the default (primary) certificate for the certificate map.
For load balancers that support directly referencing Certificate Manager certificates: the load balancer's target proxy can reference up to 100 Certificate Manager certificates. The first referenced Certificate Manager SSL certificate resource is the default (primary) certificate for the target proxy.

For more information, see:

Target proxies and SSL certificates in the load balancing documentation.
Resource quotas and limits in the Certificate Manager documentation.

Certificate selection process

The following certificate selection process applies to load balancers whose target proxies reference multiple Compute Engine SSL certificates or multiple Certificate Manager certificates.

The certificate selection process is different if a load balancer's target proxy references a Certificate Manager certificate map. For details about the certificate selection process of a certificate map, see Certificate selection logic in the Certificate Manager documentation.

After a client connects to the load balancer, the client and load balancer negotiate a TLS session. During TLS session negotiation, the client sends the load balancer a list of TLS ciphers it supports (in the ClientHello). The load balancer selects a certificate whose public key algorithm is compatible with the client. The client can also send a server name indication (SNI) hostname to the load balancer as part of this negotiation. SNI hostname data is sometimes used to help the load balancer pick which certificate it should send to the client.

If the load balancer's target proxy references only one certificate, that certificate is used, and the value of SNI hostname sent by the client isn't relevant.
If the load balancer's target proxy references two or more certificates, the load balancer uses the following process to select a single certificate:
- If the client didn't send any SNI host name in its ClientHello, the load balancer uses the first certificate in its certificate list.
- If the client sends an SNI hostname that didn't match any certificate common name (CN) and that doesn't match any certificate subject alternative name (SAN), load balancer uses the first certificate in its certificate list.
- In all other situations: The load balancer selects a certificate using the following matching process:
  - Matching is done by longest suffix against both the common name (CN) and subject alternative name (SAN) certificate attributes, with a preference for ECDSA certificates over RSA certificates.
  - To illustrate the matching method, consider a target proxy that references the following two certificates:
    - Certificate A
      - CN: cats.pets.example.com
      - SANs: cats.pets.example.com, *.pets.example.com, *.example.com
    - Certificate B
      - CN: dogs.pets.example.com
      - SANs: dogs.pets.example.com, *.pets.example.com, *.example.com
  - Now consider the following scenarios:
    - If the SNI hostname sent by the client is cats.pets.example.com, the load balancer uses Certificate A.
    - If the SNI hostname sent by the client is ferrets.pets.example.com, there's no exact match, so the load balancer selects either Certificate A or Certificate B because both include *.pets.example.com in their SANs list. You cannot control which certificate is selected in this situation.
After a certificate has been selected, the load balancer sends the client that certificate only if the selected certificate uses a public key algorithm that is compatible with a cipher sent by the client in the ClientHello. TLS negotiation fails if the client doesn't support a cipher suite that includes the public key algorithm (ECDSA or RSA) of the certificate that the load balancer selected.

Pricing

You incur networking charges when you use Google Cloud load balancers. For more information, see All networking pricing. For Certificate Manager pricing, see Pricing in the Certificate Manager documentation. There are no additional charges for using Compute Engine SSL certificate resources.

What's next

Certificate Manager overview

Encryption to the backends
Encryption in transit in Google Cloud white paper

Try it for yourself

If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

Get started for free