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

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. An Application Load Balancer or proxy Network Load Balancer that uses SSL requiresat least one private key and SSL certificate.

Note: This page discusses SSL certificates and encryption in transit between anApplication Load Balancer or proxy Network Load Balancer that uses SSL and its clients. Fordetails about encryption in transit between the Google Cloud load balancerand its backends, seeEncryption to thebackends.

Certificate configuration methods

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

• Target proxy references Compute Engine SSL certificates: with thismethod, the load balancer's target proxy can reference up to 15Compute Engine SSL certificateresources. EachCompute 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 proxyreferences a singlecertificate map. Thecertificate map supports thousands of entries by default, and can scale tomillions of entries. Each entry contains private key and certificate data.

• Target proxy references Certificate Manager certificatesdirectly: with this method, the load balancer's target proxy can referenceup to 100Certificate Managercertificates.

Load balancer support

The following table shows which certificate configuration methods eachload balancer supports.

Load balancer	Certificate configuration method
	Compute Engine SSL certificates	Certificate Manager (certificate map)	Certificate Manager (individual certificates)
Application Load Balancers (target HTTPS proxies)
Global external Application Load Balancer	Self-managed Google-managed	Self-managed Google-managed
Classic Application Load Balancer	Self-managed Google-managed	Self-managed Google-managed
Regional external Application Load Balancer	Self-managed Google-managed		Self-managed Google-managed
Regional internal Application Load Balancer	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	Self-managed Google-managed	Self-managed Google-managed
Classic proxy Network Load Balancer	Self-managed Google-managed	Self-managed Google-managed

Configuration method rules

Google Cloud enforces the following certificate configuration methodrules:

• For load balancers that support both Compute Engine SSL certificatesand Certificate Manager certificate maps: the load balancer'starget proxy can simultaneously reference both a certificate map and one ormore Compute Engine SSL certificates; however, in such a case, allCompute Engine SSL certificates are ignored, and only the certificatesfrom the certificate map are used by the load balancer.

• For load balancers that support both Compute Engine SSL certificatesand directly-attached Certificate Manager certificates: the loadbalancer's target proxy can only be configured to reference up to 15Compute Engine SSL certificates or up to 100Certificate 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 thesePublic keycertificatetypes:

• 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,seeUse self-managed SSLcertificates.

• Certificate Manager: for more information, seeDeploymentoverview in theCertificate Manager documentation.

Google-managed SSL certificates

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.

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

You can create Google-managed SSL certificates using:

• Compute Engine SSL certificate resources: only globalCompute EnginesslCertificates resources support Google-managedSSL certificates;regionSslCertificates don't support them.Global Compute Engine SSL certificates support only publicly trustedGoogle-managed certificates. For moreinformation, seeUse Google-managed SSLcertificates.
• Certificate Manager: Certificate Managercertificates (both global and regional) support bothpublicly trusted Google-managed certificates andprivately trusted Google-managed certificates. For more information, seeCertificates in theCertificate Manager documentation.

Supported key types

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

SSL certificate typearrow_forward Key typearrow_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

Important: You incur charges per TLS connection when you use RSA-3072 orRSA-4096 key types. For more information, seeAll networking pricing.To learn more about Certificate Manager certificates, see theCertificate Manager documentation.

Use certificates with ECDSA keys

This section examines why we recommend ECDSA over RSAas a best practice for certificate signing keys.

Which key type to use

ECDSA P-256 is the recommended choice of key type for most TLS certificates,offering strong cryptographic security along with excellent performancefor signing operations and efficient use of network bandwidth.

Some of the possible reasons to use other certificate key types are as follows:

• If you need to support legacy clients thatdo not support ECDSA certificates, you can provide RSA-2048 certificatesin addition to ECDSA P-256 certificates.
• If you have specific compliance requirements that require you to uselarger key sizes or particular key types, ECDSA P-384, RSA-2048, RSA-3072,and RSA-4096 keys can be used.

Why choose ECDSA over RSA

The primary advantage of ECDSA lies in its ability to provide an equivalentcryptographic security level with significantly smaller keys compared to RSA.This efficiency translates into tangible performance and resource benefits. Asmaller key does not imply weaker security—ECDSA is based on the ellipticcurve discrete logarithm problem, which provides stronger security per unit ofkey, and in some cases better computational efficiency compared to RSA.

For example:

• A 256-bit ECDSA key provides a similar security level to an RSA-3072 key.
• A 384-bit ECDSA key provides a greater security level than anywidely-supported RSA key size.

Key benefits of ECDSA:

• Performance: ECDSA signing operations are significantly lesscomputationally intensive than RSA operations providing an equivalent securitylevel. This reduces CPU load and latency, which is crucial for high-throughputor latency-sensitive systems.

• Efficiency: smaller keys and signatures require less bandwidth andstorage, which is especially beneficial for resource-constrained environmentslike mobile and IoT devices.

Multiple SSL certificates

An Application Load Balancer or proxy Network Load Balancer can host two or more SSLcertificates simultaneously when its target proxy is configured using asupported 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 EngineSSL certificates. The first referenced Compute Engine SSL certificateresource is the default (primary) certificate for the target proxy.

• For load balancers that support a Certificate Manager certificatemap: the load balancer's target proxy references a single certificate map.The certificate map supports thousands of certificate map entries. You canconfigure which certificate entry is the default (primary) certificate forthe certificate map.

• For load balancers that support directly referencingCertificate Manager certificates: the load balancer's target proxycan reference up to 100 Certificate Manager certificates. The firstreferenced Certificate Manager SSL certificate resource is thedefault (primary) certificate for the target proxy.

For more information, see:

• Target proxies andSSLcertificates in the loadbalancing documentation.

• Resource quotas andlimits in theCertificate Manager documentation.

Certificate selection process

The following certificate selection process applies to load balancers whosetarget proxies reference multiple Compute Engine SSL certificates ormultiple Certificate Manager certificates.

The certificate selection process is different if a load balancer'starget proxy references a Certificate Manager certificate map. Fordetails about the certificate selection process of a certificate map, seeCertificate selectionlogic in theCertificate Manager documentation.

Important: The certificate selection process doesn't consider thenotValidBefore andnotValidAfter attributes. The load balancer can serve anexpired certificate if an expired certificate is configured. You can avoid thissituation by using Google-managed certificates.

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

• If the load balancer's target proxy references only one certificate, thatcertificate is used, and the value of SNI hostname sent by the client isn'trelevant.

• If the load balancer's target proxy references two or more certificates, theload balancer uses the following process to select asingle certificate:

  • If the client didn't send any SNI host name in itsClientHello, the loadbalancer uses the first certificate in its certificate list.

  • If the client sends an SNI hostname that didn't match any certificatecommon name (CN) and that doesn't match any certificate subject alternativename (SAN), load balancer uses the first certificate in its certificatelist.

  • In all other situations: The load balancer selects a certificate using thefollowing matching process:

    • Matching is done by longest suffix against both the common name (CN) andsubject alternative name (SAN) certificate attributes, with a preferencefor ECDSA certificates over RSA certificates.

    • To illustrate the matching method, consider a target proxy thatreferences 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 iscats.pets.example.com,the load balancer uses Certificate A.
      • If the SNI hostname sent by the client isferrets.pets.example.com, there's no exact match, so the loadbalancer selectseither Certificate A or Certificate B becauseboth include*.pets.example.com in their SANs list. You cannotcontrol which certificate is selected in this situation.

• After a certificate has been selected, the load balancer sends the client thatcertificateonly if the selected certificate uses a public key algorithmthat is compatible with a cipher sent by the client in theClientHello. TLSnegotiation fails if the client doesn't support a cipher suite that includesthe public key algorithm (ECDSA or RSA) of the certificate that the loadbalancer selected.

Pricing

You incur networking charges when you use Google Cloud load balancers.For more information, seeAll networking pricing.For Certificate Manager pricing, seePricing in theCertificate Manager documentation. Thereare no additional charges for using Compute Engine SSL certificateresources.

What's next

• Certificate Manageroverview

• Encryption to thebackends

• Encryption in transit in Google Cloud whitepaper

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