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

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

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

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

This document provides an overview of backend authenticated TLS along withbackend mTLS. To learn more about frontend mTLS, seeMutual TLSoverview.

Backend authenticated TLS and backend mTLS can be configured on the backendservice resource of the following load balancers:

• Global external Application Load Balancers
• Regional external Application Load Balancers
• Regional internal Application Load Balancers

Features

mTLS uses public key infrastructure (PKI) to authenticate the identity of theentities communicating over the network. The infrastructure includes threecomponents: a client, a server, and a certificate authority (CA). Backendauthenticated TLS and backend mTLS add the following capabilities toApplication Load Balancers:

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

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

• You can configure intermediate certificates in addition to your trustanchors to help construct the backend certificate validation path. The useof intermediate certificates means that your backend servers don't need toprovide the complete certificate chain.

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

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

Certificate requirements

When configuring certificates for backend authenticated TLSand 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 hashfunction. Hashing algorithms such as MD4, MD5, and SHA-1 aren't supported.

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

  • Thebasic constraintsextensionmust not containCA=true.
  • Theextended key usageextensionmust containserverAuth.
  • Theextended key usageextensionmust not contain thecodeSigning,timeStamping, orOCSPSigning fields.
  • The certificatemust not be expired.

• For leaf client (load balancer) certificates used in backend mTLS, thecertificate must be aCertificate Manager certificateresource. The scope of this certificatemust beclient-auth, which indicates that this certificate is used as aclient certificate in backend mTLS.

  • Thebasic constraintsextensionmust not containCA=true.
  • Theextended key usageextensionmust containclientAuth.
  • Theextended key usageextensionmust not contain thecodeSigning,timeStamping, orOCSPSigning fields.
  • The certificatemust not be expired.

• To authenticate the server certificates that your backend presents to theload balancer, the root and intermediate certificates that are located inthe trust config must meet the following requirements:

  • Thebasic constraintsextensionmust containCA=true.
  • Thekey usageextensionmust be set tokeyCertSign.
  • Theextended key usageextensionmust contain theserverAuth field.
  • The certificatemust not be expired.

Key components of backend authenticated TLS and backend mTLS

Withbackend authenticated TLS, the load balancer can verify the identity ofthe backends that it connects to. You can configure backend authenticated TLS onan HTTP(S) load balancer that uses either HTTPS or HTTP/2 as its backend serviceprotocol. If you don't configure backend authenticated TLS, the load balanceraccepts any certificate from the backend. Usingbackend mTLS, you canadditionally configure the load balancer to present its own client certificateto 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 thebackend authentication config resource.

To configurebackend mTLS, you must create a client certificate and attach theclient certificate to the backend authentication config resource. Youcannot attach the client certificate after the backend authenticationconfig resource has been created.

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

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

Trust config

To authenticate the server certificates that your backend presents tothe load balancer, the load balancer needs to be configured with X.509certificates that establish a chain of trust to the issuer of the backend'scertificate. You configure the trust config by using aTrustConfigresource,which expresses the entire trust config 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 certificaterepresenting a root of trust. A valid server certificate must show a chain oftrust back to some trust anchor in the trust store.

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

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

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

Backend authentication config resource

The backend authentication config (BackendAuthenticationConfig resource) is attached to the backend serviceof the load balancer and performs the following functions:

• Enables backend authenticated TLS (backend authentication) by using thetrust config and the public roots of trust
• Additionally enables backend mTLS by using the client certificate

To enable backend authenticated TLS and backend mTLS, the backend authenticationconfig resource points to the following resources:

• Trust config (trustConfig):the attached trust config used to validate the server certificateprovided by the backend. The trust config isn't required whenthe backend authentication config uses the public roots of trustto validate the server certificate.

• Public roots of trust (wellKnownRoots):indicates whether the load balancer trusts backend server certificates thatare issued by public CAs, in addition to certificates trusted by the trustconfig. To learn more, seeUse public roots of trust.

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

Backend mTLS is also compatible withCompute Engine managed workloadidentities when you configure managedcertificates throughCertificate Manager. PublicPKI managed certificates aren't supported, and all client certificates musthave aclient-auth scope and comply withcertificaterequirements.

If the backend requests a client certificate, it must be configured to acceptthe client certificate. If the backend refuses the load balancer's connection,the load balancer returns an HTTP502 status code for requests that it'sproxying 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 balancerusing 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 followto configure backend authenticated TLS and backend mTLS on your load balancerusing certificates issued from your private PKI. Private PKI has the advantageof being fully under your control and isolated from the public internet's PKIsystems.

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

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

3. Create a backend authentication config resource that referencesthe trust config. If you want to configure backend mTLS,the backend authentication config resource referencesboth the trust config and the client certificate.

4. Attach the backend authentication config resource tothe backend service of the load balancer.

Note the following:

• It is not possible to send a client certificate to the backendwithout configuring backend authenticated TLS first.

• If you want to enable backend mTLS, you must create the client certificatebefore you configure the backend authentication config resource.

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

• Set up backend authenticated TLS

• Set up backend mTLS

Use public roots of trust

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

To use public roots of trust, you don't need to create a trust config and attachit to the backend authentication config resource. Instead, you need to setPUBLIC_ROOTS as a value in thewellKnownRoots field of the backendauthentication config resource. Having said that,you can also create a trust config that explicitly includesthe roots of your publicly issued certificates,in addition to certificates trusted by the trust config.

ThePUBLIC_ROOTS setting uses a set of root CAs,similar to the set of root CAs trusted by browsers, that is managed by Googleand can change over time. This presents a risk of your backend certificatesbecoming invalid when these roots change. If you need to validatepublicly issued certificates, consider choosing a well-established andtrustworthy CA and one that uses intermediate cross-signing for issuing yourbackend certificates to mitigate the risk of a root certificate expiring orbeing revoked.

Server certificate validation steps

When validating the server certificate during backend authenticated TLS, orbackend 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 thecertificate it presents to the load balancer by signing a piece ofinformation using its private key and sending it to the load balancer as apart of theCertificateVerify message. The load balancer then verifiesthis signature using the public key from the server's certificate. If thesignature verification fails, it indicates that the backend server doesn'tpossess the private key corresponding to the certificate. In such cases, theload 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 thewellKnownRoots attribute set toPUBLIC_ROOTS, the load balancer attemptsto verify a chain of trust between the server certificate and the configuredtrust anchor. The verification checks include the following:

   • The backend's server certificate, intermediate certificates (if provided), and the configured root certificate comply with thecertificate 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.
   Note: Self-signed client certificates fail to form a valid chain of trust and are always rejected.

3. Establish a connection with the backend.

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

   However, if the certificate validation fails, the load balancer terminatesthe connection to the backend, sends an HTTP502 status code to theclient, and logs the termination reason to Cloud Logging. In the event ofa certificate validation error, subsequent incoming requests trigger the loadbalancer to reinitiate the backend connection.

   The backend connection can also fail if the backend server refuses theconnection. Withbackend mTLS, this can happen because it finds the clientcertificate to be invalid. When the connection to the backend fails, the loadbalancer responds to proxied requests with an HTTP502 status code and logsa generic error reason to Cloud Logging.

Error handling and logging

Application Load Balancers provide detailed logging capabilities that allow youto monitor server certificate validation, identify potential issues, andtroubleshoot connection problems. This section outlines the different types oferrors that can occur during mTLS validation and how they are logged.

If the server certificate validation fails, the connection is terminated and theerrors are logged to Cloud Logging. These errors are described in thefollowing table.

Limitations

• Backend authenticated TLS and backend mTLS isn't supported onclassic Application Load Balancers.

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

  • Global internet NEG backends

  • App Engine backends

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

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

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

  • 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 intermediatecertificates combined, with a separate limit of 100 for intermediatecertificates. No more than three intermediate certificates can share thesame Subject and Subject Public Key information.

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

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

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

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

What's next

• Set up backend authenticated TLS using self-managed certificates