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 the following load balancers:

  • Global external Application Load Balancers
  • Regional external Application Load Balancers
  • Regional internal Application Load Balancers
  • Cross-region internal 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, 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.

  • To authenticate the server certificates that your backend presents to the load balancer, the root and intermediate certificates that are located in the trust config must meet 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