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 method

For Application Load Balancers using target HTTPS proxies, the load balancer's target proxy must reference between one and 15 Compute Engine SSL certificates. Each Compute Engine SSL certificate resource contains the private key, corresponding certificate, and —optionally—CA certificates.

Load balancer support

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

Load balancer Certificate configuration method: Target proxy references...
Compute Engine SSL certificates A Certificate Manager certificate map Certificate Manager certificates directly
Application Load Balancers (target HTTPS proxies)
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

Certificate types

You can create self-managed SSL certificates for your load balancers.

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.

Supported key types

The following key types are supported for regional self-managed Compute Engine SSL certificates:

  • RSA-2048
  • RSA-3072
  • RSA-4096
  • ECDSA P-256
  • ECDSA P-384

Use certificates with ECDSA keys

This section examines why we recommend ECDSA over RSA as 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 performance for 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 that do not support ECDSA certificates, you can provide RSA-2048 certificates in addition to ECDSA P-256 certificates.
  • If you have specific compliance requirements that require you to use larger 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 equivalent cryptographic security level with significantly smaller keys compared to RSA. This efficiency translates into tangible performance and resource benefits. A smaller key does not imply weaker security—ECDSA is based on the elliptic curve discrete logarithm problem, which provides stronger security per unit of key, 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 any widely-supported RSA key size.

Key benefits of ECDSA:

  • Performance: ECDSA signing operations are significantly less computationally intensive than RSA operations providing an equivalent security level. This reduces CPU load and latency, which is crucial for high-throughput or latency-sensitive systems.

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

Multiple SSL certificates

An Application 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 more information, see Target proxies and SSL certificates in the load balancing documentation.

Certificate selection process

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

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.

What's next