SSL certificates overview

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. Google Cloud proxy load balancers whose forwarding rules reference a target HTTPS proxy or target SSL proxy require a private key and SSL certificate as part of the load balancer's target proxy configuration.

Note: This page discusses SSL certificates in the context of encryption in transit between a Google Cloud proxy load balancer and (downstream) clients that connect to the Google Cloud load balancer. For details about encryption in transit between the Google Cloud load balancer and its (upstream) backends, see Encryption to the backends.

Certificate configuration methods

Google Cloud offers two methods to configure SSL certificates for HTTP(S) and SSL proxy load balancers. Both methods support self-managed and Google-managed SSL certificates.

• Compute Engine SSL certificate resource: With this method, the target proxy for a global external Application Load Balancer, classic Application Load Balancer, external proxy Network Load Balancer, regional external Application Load Balancer, or internal Application Load Balancer is configured to reference a Compute Engine SSL certificate resource. The SSL certificate resource contains the private key, corresponding certificate, and —optionally—CA certificates. This method supports all Network Service Tiers that are supported by the load balancer.

• Certificate Manager: With this method, the target proxy for a global external Application Load Balancer, classic Application Load Balancer, or external proxy Network Load Balancer is configured to reference a certificate map. The certificate map contains one or more certificate entries. Each certificate entry references a single Certificate Manager certificate resource, and each certificate resource contains a private key and certificate. With Certificate Manager, a target HTTPS proxy or target SSL proxy can reference a certificate map with thousands of SSL certificate entries. This method is only available when the load balancer uses the Premium Network Service Tier.

  For cross-region internal Application Load Balancers, regional internal Application Load Balancers, and regional external Application Load Balancers, Certificate Manager certificates are attached to the target proxy. Certificate maps are not supported.

  For more information, see the following documentation:

  • Certificate Manager overview
  • Deployment overview

Certificate types

You can create your own certificates or Google can manage them for you:

• 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

  For more information about self-managed Compute Engine SSL certificates, see Use self-managed SSL certificates.

  For more information about self-managed SSL certificates and Certificate Manager, see Upload a self-managed certificate in the Certificate Manager documentation or Deploy a self-managed certificate for an end-to-end tutorial.

• 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, and they don't support wildcard common names.

  For more information about Google-managed Compute Engine SSL certificates, see Use Google-managed SSL certificates.

  Certificate Manager supports Google-managed SSL certificates using load-balancer authorization, DNS authorization, and integration with a Certificate Authority Service. For more information about Google-managed SSL certificates Certificate Manager, see Deployment overview in the Certificate Manager documentation.

Certificates and Google Cloud load balancers

The following sections describe how each Application Load Balancer supports the different certificate configuration methods.

Compute Engine SSL certificates

The following table shows which Google Cloud load balancers support self-managed Compute Engine SSL certificates or Google-managed Compute Engine SSL certificates or both:

	Compute Engine SSL certificate support
Load balancer	Self-managed	Google-managed
Global external Application Load Balancer ^*	sslCertificates	sslCertificates
Classic Application Load Balancer ^*	sslCertificates	sslCertificates
Regional external Application Load Balancer ^†	regionSslCertificates
Regional internal Application Load Balancer ^†	regionSslCertificates
Cross-region internal Application Load Balancer ^*
External proxy Network Load Balancer (with SSL proxy) ^‡	sslCertificates	sslCertificates

---

^* The global external Application Load Balancer, cross-region internal Application Load Balancer, and classic Application Load Balancer use global target HTTPS proxies, even when a classic Application Load Balancer uses Standard tier.

^† The regional external Application Load Balancer and internal Application Load Balancer use regional target HTTPS proxies.

^‡ The external proxy Network Load Balancer uses global target SSL proxies, even in Standard tier.

Certificate Manager SSL certificates

The following table shows which Google Cloud load balancers support Certificate Manager self-managed or Google-managed certificates or both.

Load balancer	Google-managed certificate			Self-managed certificate
	DNS authorization	Load balancer authorization	Certificate Authority Service (CA Service)
Global external Application Load Balancer	info	info	info	info
Classic Application Load Balancer	info	info	info	info
Global external proxy Network Load Balancer	info	info	info	info
Cross-region internal Application Load Balancer	info		info	info
Regional external Application Load Balancer	info		info	info
Regional internal Application Load Balancer	info		info	info

Multiple SSL certificates

You can use the same target HTTPS proxy or target SSL proxy to host multiple certificates—common when the load balancer supports multiple domain names. You can configure a single forwarding rule (a single IP address and port) to reference a common target proxy, or you can configure multiple forwarding rules (different IP addresses and ports) to reference a common target proxy.

Multiple Compute Engine SSL certificate resources

When using Compute Engine SSL certificate resources, each target proxy resource can reference up to a non-configurable maximum number of SSL certificates per target HTTPS or target SSL proxy. For more information, see Target pools and target proxies in the load balancing quotas and limits documentation.

The first Compute Engine SSL certificate resource referenced by a load balancer's target proxy is considered the default (primary) certificate for the load balancer.

Multiple SSL certificates using Certificate Manager

When using Certificate Manager with a certificate map on a load balancer, each target proxy resource references a single certificate map. A certificate map references one or more certificate entries, and you can configure which certificate entry is the default (primary) certificate for the map. The number of maps, entries, and Certificate Manager certificates are configurable, per-project quotas. For more information, see Resource quotas in the Certificate Manager documentation.

If you're using a load balancer that supports Certificate Manager and you need to host more than a few SSL certificates per target proxy, make sure you're using Certificate Manager instead of Compute Engine SSL certificate resources.

Note: For cross-region internal Application Load Balancers, regional internal Application Load Balancers, and regional external Application Load Balancers, Certificate Manager certificates are attached to the target proxy. Certificate maps are not supported.

Certificate selection method

After a client connects to an HTTP(S) or SSL proxy 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.

You can model the process that Google Cloud proxy load balancers use to select a certificate to send to a client as follows. In your model, begin with all SSL certificates that have been configured on the target HTTPS proxy or target SSL proxy—regardless of the configuration method.

Note: The term "default (primary) SSL certificate" is either the first Compute Engine SSL certificate referenced by the target proxy or a certificate that's been set as primary in the Certificate Manager map referenced by the target proxy.

1. The load balancer selects a single certificate candidate:

   • If a load balancer's target proxy references only one Compute Engine SSL certificate resource, or if a load balancer's target proxy references a Certificate Manager map with only one certificate entry, the load balancer uses the one and only configured certificate as the certificate candidate. The value of the SNI hostname (if provided) does not influence the load balancer at all. Proceed to step 2.

   • If a load balancer's target proxy references two or more Compute Engine SSL certificate resources, or if a load balancer's target proxy references a Certificate Manager map with two or more certificate entries, the load balancer uses the following process to select a single certificate candidate:

     • If the client does not send any SNI host name in its ClientHello, the load balancer uses the default (primary) SSL certificate as the certificate candidate. Proceed to step 2.

     • If the client sends an SNI hostname that does not match any certificate common name (CN) and does not match any certificate subject alternative name (SAN), load balancer uses the default (primary) SSL certificate as the certificate candidate. Proceed to step 2.

     • The load balancer selects a certificate candidate that matches the SNI hostname sent by the client. Matching is done by longest prefix 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 one certificate whose CN is cats.pets.example.com and another certificate whose CN is dogs.pets.example.com. In addition to including each CN value in its SANs, each certificate includes *.pets.example.com, and *.example.com in its SANs.

       • If the SNI hostname provided is cats.pets.example.com, the load balancer uses the certificate whose CN is cats.pets.example.com as the certificate candidate. Proceed to step 2.
       • If the SNI hostname provided is ferrets.pets.example.com, the load balancer uses one of the two certificates as the certificate candidate because both configured certificates have SANs that include *.pets.example.com. You cannot control which of the two certificates becomes the certificate candidate in this situation. Proceed to step 2.

2. The certificate candidate is sent to the client if the certificate candidate uses a public key algorithm compatible with one of the client's stated ciphers.

   • TLS negotiation can fail if the client does not support a cipher suite that includes the public key algorithm (ECDSA or RSA) of the certificate.
   • The load balancer does not use the certificate's notValidBefore and notValidAfter attributes as any part of the candidate selection method. For example, the load balancer can serve an expired certificate if the expired certificate was selected as the certificate candidate.

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

• For more information about Compute Engine SSL certificates, see the following pages:

  • For more information about self-managed Compute Engine SSL certificates, see Use self-managed SSL certificates.
  • For more information about Google-managed Compute Engine SSL certificates, see Use Google-managed SSL certificates.
  • To learn about quotas and limits (including supported key lengths) for Compute Engine SSL certificates, see SSL certificates and Target pools and target proxies in the load balancer documentation.

• For more information about Certificate Manager, see the the following pages:

  • Certificate Manager overview.
  • For more information about self-managed SSL certificates and Certificate Manager, see Upload a self-managed certificate in the Certificate Manager documentation or Deploy a self-managed certificate for an end-to-end tutorial.
  • For more information about Google-managed SSL certificates and Certificate Manager, see Manage certificates in the Certificate Manager documentation.
  • To learn about quotas and limits for Certificate Manager, see Resource quotas in the Certificate Manager documentation.

• For details about how to configure SSL certificates for proxy load balancers managed by GKE, see GKE Ingress for HTTP(S) Load Balancing, the GKE Gateway API documentation, and Container-native load balancing through standalone zonal NEGs.

• For details about load balancers and encryption in transit, see Encryption to the backends and the 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