Backend authenticated TLS and backend mTLS overview

When a load balancer connects to backends that are within Google Cloud, the load balancer accepts any certificate that your backends present. In such cases, the load balancer doesn't perform any certificate validation.

With backend authenticated TLS or backend authentication, the load balancer can verify the identity of the backends that it connects to. And with backend mTLS, the load balancer can additionally prove its identity to backends by using a client TLS certificate.

The following diagram shows the difference between frontend and backend mTLS, focusing on the role of the load balancer in each case. In frontend mTLS, the load balancer acts as the server, verifying the client's identity. In backend mTLS, the load balancer acts as the client, proving its identity to the backend.

Frontend and backend mTLS.
Frontend and backend mTLs (click to enlarge).

mTLS operates independently on the frontend and the backend. You can configure mTLS on either the frontend, the backend, or both the frontend and the backend.

This document provides an overview of backend authenticated TLS along with backend mTLS. To learn more about frontend mTLS, see Mutual TLS overview.

Backend authenticated TLS and backend mTLS can be configured on the backend service resource of global external Application Load Balancers.

Features

mTLS uses public key infrastructure (PKI) to authenticate the identity of the entities communicating over the network. The infrastructure includes three components: a client, a server, and a certificate authority (CA). Backend authenticated TLS and backend mTLS add the following capabilities to Application Load Balancers:

  • The load balancer can validate certificates presented by backends against your own trust anchors. You can upload multiple trust anchors to enable seamless migration from an earlier PKI to a new one without downtime.

  • The load balancer can validate TLS certificates of backends against public roots of trust (web PKI).

  • You can configure intermediate certificates in addition to your trust anchors to help construct the backend certificate validation path. The use of intermediate certificates means that your backend servers don't need to provide the complete certificate chain.

  • You can configure a TLS Server Name Indication (SNI) hostname for your backend service. During the TLS handshake, the load balancer includes this SNI hostname in the ClientHello message that it sends to the backend. The backend then responds with its TLS certificate, and the load balancer verifies that at least one of this certificate's Subject Alternative Name (SAN) fields matches the hostname or any of the SAN fields configured for the backend service.

  • You can configure your load balancer's backend service to use mTLS so that the load balancer can prove its identity to the backends. This authentication is carried out using a client (load balancer) certificate that the load balancer presents to the backend.

Certificate requirements

When configuring certificates for backend authenticated TLS and backend mTLS, ensure that they comply with these requirements:

  • Modern cryptography tools form the basis of mTLS authentication. Certificates must use either RSA or ECDSA algorithms for key exchange. Hashing algorithms must use SHA-256 or a stronger cryptographic hash function. Hashing algorithms such as MD4, MD5, and SHA-1 aren't supported.

  • Leaf server certificates that are provided by the backend have the following requirements:

  • For leaf client (load balancer) certificates used in backend mTLS, the certificate must be a Certificate Manager certificate resource. The scope of this certificate must be client-auth, which indicates that this certificate is used as a client certificate in backend mTLS.

  • Root and intermediate certificates that are used with backend authenticated TLS have the following requirements:

Key components of backend authenticated TLS and backend mTLS

With backend authenticated TLS, the load balancer can verify the identity of the backends that it connects to. You can configure backend authenticated TLS on an HTTP(S) load balancer that uses either HTTPS or HTTP/2 as its backend service protocol. If you don't configure backend authenticated TLS, the load balancer accepts any certificate from the backend. Using backend mTLS, you can additionally configure the load balancer to present its own client certificate to the backend, which the backend can use to authenticate the load balancer.

To configure backend authenticated TLS, you need to do the following:

  • Create a trust config resource.
  • Create a Backend Authentication Config resource.
  • Update the TLS setting attribute on the backend service, pointing it to the Backend Authentication Config resource.

To configure backend mTLS, you must create a client certificate and attach the client certificate to the Backend Authentication Config resource. You cannot attach the client certificate after the Backend Authentication Config resource has been created.

The following diagram shows the different components, attached to the backend service of an Application Load Balancer, that enable backend authenticated TLS and backend mTLS.

Backend authenticated TLS and backend mTLS components.
Backend authenticated TLS and backend mTLS components (click to enlarge).

The information that follows provides an overview of these different components used to configure backend authenticated TLS and backend mTLS.

Trust config

To authenticate the server certificates that your backend presents to the load balancer, the load balancer needs to be configured with X.509 certificates that establish a chain of trust to the issuer of the backend's certificate. You configure the trust config by using a TrustConfig resource, which expresses the entire trust configuration and contains a single trust store.

A trust store encapsulates a trust anchor (root certificate) and, optionally, one or more intermediate certificates. A trust anchor is a certificate representing a root of trust. A valid server certificate must show a chain of trust back to some trust anchor in the trust store.

An intermediate certificate is a certificate that is part of a chain of trust leading back to a trust anchor in the trust store. It is used, along with any additional intermediate CAs included with the leaf certificate, to build the trust chain during the validation process. Creating an intermediate certificate is optional.

If you need to use a certificate that is self-signed, expired, doesn't chain to a specified root of trust, or has failed validation, you can add such a certificate to an allowlist in the trust config. Creating a self-signed certificate that can be added to an allowlist is also optional.

The trust store doesn't contain any private keys because only the certificates are necessary to verify a chain of trust.

Backend Authentication Config resource

The Backend Authentication Config resource, attached to the backend service of the load balancer, enables the following:

  • Backend authenticated TLS (using the trust config and public roots of trust)
  • Backend mTLS (using the client certificate)

To enable backend authenticated TLS and backend mTLS, the Backend Authentication Config resource points to the following resources:

  • Trust config (trustConfig): the attached trust config used to validate the server certificate provided by the backend.

  • Public roots of trust (wellKnownRoots): indicates whether the load balancer trusts backend server certificates that are issued by public CAs, in addition to certificates trusted by the trust config. To learn more, see Using public roots of trust.

  • Client certificate (clientCertificate): the client certificate that the load balancer uses to express its identity to the backend, if the connection to the backend uses mTLS. For backend authenticated TLS (backend authentication), this field can be empty, in which case the load balancer only authenticates the backend, but not itself, to the backend.

Backend service

Within the backend service, the tlsSettings attribute points to the following resources in order to validate the backend certificate.

  • Backend Authentication Config (authenticationConfig)
  • SNI hostname (sni)
  • Accepted SANs (subjectAltNames)

The SNI (sni) and SAN (subjectAltNames) fields in the tlsSettings attribute control how the load balancer validates the backend's certificate based on the certificate's SAN values. These fields influence the validation process regardless of whether backend authenticated TLS is configured.

When the SNI field is set (tlsSettings.sni), the load balancer does the following:

  • Sends the SNI hostname to the backend server during the TLS handshake.
  • Verifies that the backend's TLS certificate includes a SAN that matches the SNI hostname.

By default, the load balancer checks that the backend's TLS certificate includes a SAN that matches the SNI hostname. However, if SANs are configured on the backend service (tlsSettings.subjectAltNames), the load balancer does the following:

  • Ignores the SNI hostname for SAN verification.
  • Verifies that the backend's TLS certificate includes a SAN that matches one of the accepted SANs (subjectAltNames) configured on the backend service.

Client certificate

In addition to backend authenticated TLS (backend authentication), you can configure a load balancer's backend service to use mTLS, so that the load balancer can prove its identity to the backend. This authentication uses a client (load balancer) certificate that the load balancer presents to the backend.

To configure backend mTLS, you need to do the following:

  • Create a client certificate resource containing the client (load balancer) certificate and its private key.
  • Attach the client certificate to the Backend Authentication Config resource.

Backend mTLS is also compatible with Compute Engine managed workload identities when you configure managed certificates through Certificate Manager. Public PKI managed certificates aren't supported, and all client certificates must have a client-auth scope and comply with certificate requirements.

If the backend requests a client certificate, it must be configured to accept the client certificate. If the backend refuses the load balancer's connection, the load balancer returns an HTTP 502 status code for requests that it's proxying and logs a generic status to Cloud Logging.

Configure backend authenticated TLS and backend mTLS on the load balancer

You can configure backend authenticated TLS and backend mTLS on the load balancer using either a private PKI or public roots of trust.

Use private PKI

The following is a high-level overview of the key steps that you need to follow to configure backend authenticated TLS and backend mTLS on your load balancer using certificates issued from your private PKI. Private PKI has the advantage of being fully under your control and isolated from the public internet's PKI systems.

  1. Create a trust config resource comprising the trust anchor (root certificate) and intermediate certificates that serve as roots of trust.

  2. To configure backend mTLS, create a client certificate containing the client (load balancer) certificate and its private key.

  3. Create a Backend Authentication Config resource that references the trust config. If you want to configure backend mTLS, the Backend Authentication Config resource references both the trust config and the client certificate.

  4. Attach the Backend Authentication Config resource to the backend service of the load balancer.

To learn more about this setup in detail, see the following guides:

Use public roots of trust

In addition to using certificates issued from your private PKI to enable backend authenticated TLS, you can also use public roots of trust to validate the backend certificate.

To use public roots of trust, you don't need to create a trust config and attach it to the Backend Authentication Config resource. Instead, you need to set PUBLIC_ROOTS as a value in the wellKnownRoots field of the Backend Authentication Config resource. Having said that, you can also create a trust config that explicitly includes the roots of your publicly issued certificates, in addition to certificates trusted by the trust config.

The PUBLIC_ROOTS setting uses a set of root CAs, similar to the set of root CAs trusted by browsers, that is managed by Google and can change over time. This presents a risk of your backend certificates becoming invalid when these roots change. If you need to validate publicly issued certificates, consider choosing a well-established and trustworthy CA and one that uses intermediate cross-signing for issuing your backend certificates to mitigate the risk of a root certificate expiring or being revoked.

Server certificate validation steps

When validating the server certificate during backend authenticated TLS, or backend authentication, the load balancer does the following:

  1. Verify that the server possesses the certificate's private key.

    The server proves possession of the private key associated with the certificate it presents to the load balancer by signing a piece of information using its private key and sending it to the load balancer as a part of the CertificateVerify message. The load balancer then verifies this signature using the public key from the server's certificate. If the signature verification fails, it indicates that the backend server doesn't possess the private key corresponding to the certificate. In such cases, the load balancer terminates the TLS handshake without logging any errors.

  2. Verify the chain of trust.

    If the trust config includes at least one trust anchor or has the wellKnownRoots attribute set to PUBLIC_ROOTS, the load balancer attempts to verify a chain of trust between the server certificate and the configured trust anchor. The verification checks include the following:

    • The backend's server certificate, intermediate certificates (if provided), and the configured root certificate comply with the certificate requirements.
    • For all the certificates in the chain of trust, the subject field in the parent certificate matches the issuer field in the child certificate. This verification helps to ensure that the parent certificate's identity (subject) is the same as the identity listed as the issuer in the child certificate.
    • For all the certificates in the chain of trust, the subject key identifier (SKID) of the parent certificate matches the authority key identifier (AKID) in the child certificate. This match confirms that the child certificate was issued by the correct root authority and that it can be trusted because the root's public key is being referenced in the AKID for verifying the certificate's validity.

  3. Establish a connection with the backend.

    If certificate validation succeeds, the load balancer proceeds with the connection to the backend.

    However, if the certificate validation fails, the load balancer terminates the connection to the backend, sends an HTTP 502 status code to the client, and logs the termination reason to Cloud Logging. In the event of a certificate validation error, subsequent incoming requests trigger the load balancer to reinitiate the backend connection.

    The backend connection can also fail if the backend server refuses the connection. With backend mTLS, this can happen because it finds the client certificate to be invalid. When the connection to the backend fails, the load balancer responds to proxied requests with an HTTP 502 status code and logs a generic error reason to Cloud Logging.

Limitations

  • Backend authenticated TLS and backend mTLS can only be configured for global external Application Load Balancers. Classic Application Load Balancers don't support backend authenticated TLS and backend mTLS.

  • Backend authenticated TLS and backend mTLS isn't supported for the following backend types:

    • Global internet NEG backends

    • App Engine backends

  • To enable backend mTLS, you must also configure backend authenticated TLS.

  • If you want to enable backend mTLS, you must create the client certificate before you configure the Backend Authentication Config resource.

  • Health checks used by backends don't implement TLS authentication or mTLS capabilities. You must configure the backends with health check endpoints that can respond to HTTP or HTTPS requests.

  • The load balancer doesn't pass the client's SNI hostname from the frontend TLS connection when connecting to a backend. However, backends can access the client's SNI hostname using a custom request header.

  • For backend mTLS, the client certificate keys are restricted to the following:

    • RSA keys can range from 2048 to 4096 bits.
    • ECDSA keys can use the P-256 or P-384 curves.

  • Backend authenticated TLS doesn't support certificate revocation checks.

Quotas and limits

  • A single trust store can hold up to 200 trust anchors and intermediate certificates combined, with a separate limit of 100 for intermediate certificates. No more than three intermediate certificates can share the same Subject and Subject Public Key information.

  • The maximum depth of a certificate chain is 10 certificates, including the root and leaf certificates. The maximum number of intermediate certificates that can be evaluated while attempting to build the chain of trust is 100.

  • Backend authenticated TLS limits the certificate chain received from the backend to no more than 16 KB and 10 certificates.

  • Root certificates used for validation cannot contain more than 10 name constraints.

  • The maximum number of subject alternative names allowed in the tlsSettings.subjectAltNames[] field is 5.

What's next