SSL certificates overview  |  Load Balancing  |  Google Cloud (2024)

Transport Layer Security (TLS) is used to encrypt information while it is sentover a network, providing privacy between a client and a server or loadbalancer. Google Cloud proxy load balancers whose forwarding rules reference atarget HTTPS proxy or target SSL proxy require a private key and SSL certificateas part of the load balancer's target proxy configuration.

Certificate configuration methods

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

• Compute Engine SSL certificate resource: With this method, thetarget 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 configuredto reference a Compute Engine SSL certificateresource. The SSLcertificate resource contains the private key, corresponding certificate, and—optionally—CA certificates. This method supports all NetworkService Tiers that are supported by the loadbalancer.

• Certificate Manager: With this method, the target proxy for aglobal external Application Load Balancer, classic Application Load Balancer, or external proxy Network Load Balancer isconfigured to reference a certificate map. The certificate map contains oneor more certificate entries. Each certificate entry references a singleCertificate Manager certificate resource, and each certificateresource contains a private key and certificate. WithCertificate Manager, a target HTTPS proxy or target SSL proxy canreference a certificate map with thousands of SSL certificate entries. Thismethod is only available when the load balancer uses the Premium NetworkService Tier.

  For cross-region internal Application Load Balancers, regional internal Application Load Balancers, andregional external Application Load Balancers, Certificate Managercertificates are attached to the target proxy. Certificate maps are notsupported.

  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 keycertificate types:

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

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

  For more information about self-managed SSL certificates andCertificate Manager, see Upload a self-managedcertificate in theCertificate Manager documentation or Deploy a self-managedcertificate for an end-to-endtutorial.

  See Also

  Renew an SSL/TLS certificateBuild and use a local module | Terraform | HashiCorp DeveloperCLI Commands - CDK for Terraform | Terraform | HashiCorp DeveloperHow to Get an SSL Certificate in 8 Simple Steps

• Google-managed SSL certificates are certificates that Google Cloudobtains, manages, and renews automatically. Google-managed certificates arealways Domain Validation (DV) certificates. They don't demonstrate theidentity of an organization or individual associated with the certificate, andthey don't support wildcard common names.

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

  Certificate Manager supports Google-managed SSL certificates usingload-balancer authorization, DNS authorization, and integration with aCertificate Authority Service. For more information about Google-managed SSLcertificates Certificate Manager, seeDeployment overview in theCertificate Manager documentation.

Certificates and Google Cloud load balancers

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

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

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

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

Multiple SSL certificates

You can use the same target HTTPS proxy or target SSL proxy to host multiplecertificates—common when the load balancer supports multiple domain names.You can configure a single forwarding rule (a single IP address and port) toreference 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 proxyresource can reference up to a non-configurable maximum number of SSLcertificates per target HTTPS or target SSL proxy. For more information, seeTarget pools and targetproxies in theload balancing quotas and limits documentation.

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

Multiple SSL certificates using Certificate Manager

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

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

Certificate selection method

After a client connects to an HTTP(S) or SSL proxy load balancer, the clientand load balancer negotiate a TLS session. During TLS session negotiation, theclient sends the load balancer a list of TLS ciphers it supports (in theClientHello). The load balancer selects a certificate whose public keyalgorithm is compatible with the client. The client can also send a server nameindication (SNI) hostname to the load balancer as part of this negotiation. SNIhostname data is sometimes used to help the load balancer pick which certificateit should send to the client.

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

1. The load balancer selects a single certificate candidate:

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

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

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

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

     • The load balancer selects a certificate candidate that matches theSNI hostname sent by the client. Matching is done by longest prefixagainst both the common name (CN) and subject alternative name (SAN)certificate attributes, with a preference for ECDSA certificates overRSA certificates. To illustrate the matching method, consider a targetproxy that references one certificate whose CN iscats.pets.example.com and another certificate whose CN isdogs.pets.example.com. In addition to including each CN value in itsSANs, each certificate includes *.pets.example.com, and*.example.com in its SANs.

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

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

   • TLS negotiation can fail if the client does not support a cipher suitethat includes the public key algorithm (ECDSA or RSA) of the certificate.
   • The load balancer does not use the certificate's notValidBefore andnotValidAfter attributes as any part of the candidate selection method.For example, the load balancer can serve an expired certificate if theexpired 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 theCertificate Manager documentation. Thereare no additional charges for using Compute Engine SSL certificateresources.

What's next

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

  • For more information about self-managed Compute Engine SSLcertificates, see Use self-managed SSLcertificates.
  • For more information about Google-managed Compute Engine SSLcertificates, see Use Google-managed SSLcertificates.
  • To learn about quotas and limits (including supported key lengths) forCompute Engine SSL certificates, see SSLcertificates and Target poolsand targetproxies in theload balancer documentation.

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

  • Certificate Manageroverview.
  • For more information about self-managed SSL certificates andCertificate Manager, see Upload a self-managedcertificate in theCertificate Manager documentation or Deploy a self-managedcertificate for an end-to-endtutorial.
  • For more information about Google-managed SSL certificates andCertificate Manager, see Managecertificates in theCertificate Manager documentation.
  • To learn about quotas and limits for Certificate Manager, seeResource quotas in theCertificate Manager documentation.

• For details about how to configure SSL certificates for proxy load balancersmanaged by GKE, see GKE Ingress forHTTP(S) Load Balancing, theGKE GatewayAPI documentation, andContainer-native load balancing through standalone zonalNEGs.

• For details about load balancers and encryption in transit, seeEncryption to thebackendsand the Encryption in Transit inGoogle Cloud white paper.