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. 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.
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:
The following table shows the different types of certificate resources that can be attached to either a target HTTPS proxy or a target SSL proxy of Google Cloud proxy load balancers. Compute Engine SSL certificates are attached directly to the target proxy whereas Certificate Manager SSL certificates can be attached either directly to the target proxy or through a certificate map.
| Proxy load balancer | Compute Engine SSL certificates | Certificate Manager SSL certificates | |
|---|---|---|---|
| Attached to the target proxy through a certificate map | Attached directly to the target proxy | ||
| Global external Application Load Balancer (with an HTTPS proxy) | |||
| Classic Application Load Balancer (with an HTTPS proxy) | |||
| Global external proxy Network Load Balancer (with an SSL proxy) | |||
| Classic proxy Network Load Balancer (with an SSL proxy) | |||
| Cross-region internal Application Load Balancer (with an HTTPS proxy) | |||
| Regional external Application Load Balancer (with an HTTPS proxy) | |||
| Regional internal Application Load Balancer (with an HTTPS proxy) | |||
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.
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.
Google Cloud proxy load balancers follow the steps outlined in this section to select a certificate and send it to the client. The term "default (primary) SSL certificate", as used in the following steps, refers to the first Compute Engine SSL certificate referenced by the target proxy.
The load balancer selects a single certificate candidate:
If a load balancer's target proxy references only one Compute Engine SSL certificate resource, 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, 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.comand another certificate whose CN isdogs.pets.example.com. In addition to including each CN value in its SANs, each certificate includes*.pets.example.com, and*.example.comin its SANs.- If the SNI hostname provided is
cats.pets.example.com, the load balancer uses the certificate whose CN iscats.pets.example.comas 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.
- If the SNI hostname provided is
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
notValidBeforeandnotValidAfterattributes 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