Mutual TLS, or mTLS, is an industry standard protocol for mutual authenticationbetween a client and a server. It ensures that both the client and serverauthenticate each other by verifying that each holds a valid certificate issuedby a trusted certificate authority (CA). Unlike standard TLS, where only theserver is authenticated, mTLS requires the client and server to presentcertificates, confirming the identities of both parties before communication isestablished.

mTLS is configured on the target HTTPS proxy resource of all theApplication Load Balancers:

• Global external Application Load Balancer
• Classic Application Load Balancer
• Regional external Application Load Balancer
• Regional internal Application Load Balancer
• Cross-region internal Application Load Balancer

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). mTLS for loadbalancers supports the following features:

• Verify that the client presenting the certificate possesses its private key.

• Validate client certificates in either of the two modes:

  • Reject invalid certificates: Enforces strict authentication by rejectingrequests if the client certificate chain cannot be validated.

  • Allow invalid or missing certificates: Provides flexibility by passingall requests to the backend, even if a client certificate is missing orinvalid.

• Validate client certificates against an uploaded PKI anchor (rootcertificate), with the option to add multiple anchors separately to enableseamless migration from an old PKI to a new one without downtime.

• Provide additional intermediate certificates to help construct the clientcertificate validation path against specified PKI anchors (rootcertificates). These intermediate certificates allow mTLS to work withclients that don't provide the complete certificate chain.

• Generate and pass a fingerprint of the certificate to the backend as a customrequest header.

• Pass selected fields extracted from the certificate to the backendby using custom headers.

• Pass the validation result and any validation errors to the backendby using custom headers.

Certificate requirements

When configuring certificates for mTLS, ensure they comply with theserequirements:

• 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.
• For client (leaf) certificates:
  • TheBasic Constraintsextension mustnot containCA=true.
  • TheExtended Key Usageextension must containclientAuth.
  • TheExtended Key Usageextension mustnot contain thecodeSigning,timeStamping, orOCSPSigning fields.
  • The certificate must not be expired.
  • The client certificate cannot be aself-signed certificate.
• For root and intermediate certificates:
  • TheBasic Constraintsextension must containCA=true.
  • TheKey Usageextension must be set tokeyCertSign.
  • TheExtended Key Usageextension should contain theclientAuth field.
  • The certificate must not be expired.

Architecture of an mTLS deployment

With mTLS, you can configure a trust config resource, which contains a truststore. The trust store encapsulates a trust anchor (root certificate) and,optionally, one or more intermediate certificates. When the load balancerreceives a client certificate, the load balancer validates it byestablishing a chain of trust from the client certificate back to the configuredtrust anchor.

The following is a brief overview of the different resources you need toconfigure to set up mTLS for the load balancer:

• Trust config. Contains a single trust store resource, which in turnencapsulates a trust anchor (root certificate) and, optionally, one or moreintermediate certificates. The trust config is used to establish a chain oftrust between the client certificate and the trust anchor. For moreinformation, seeTrustconfigs.

  Optionally, if you need to use a certificate that has been self-signed, isexpired, or is otherwise invalid, or if you don't have access to the rootand intermediate certificates, you can add that certificate to the trustconfig in theallowlistedCertificates field. You don't need a trust storeto add a certificate to an allowlist.

  Adding a certificate to the allowlist means that the certificate is alwaysconsidered valid as long as the certificate is parseable, proof of privatekey possession is established, and constraints on the SAN field of thecertificate are met.

• Trust store. Contains the trust anchor and intermediate certificateauthority (CA) certificates that is used to establish a chain of trust andvalidate the client certificate. A CA is used to issue trusted certificatesfor the client. The CA is identified by the load balancer's trust anchor(root certificate) or the intermediate CA certificates.

  You can upload the following types of root and intermediate certificates tothe trust store:

  • Certificates issued by third-party CAs of your choice.
  • Certificates issued by private CAs in your control, as described inSetup mutual TLS with a privateCA.
  • User-provided certificates, as described inSet up mutual TLS withuser-providedcertificates.

• Client Authentication (also known asServerTLSPolicy).Specifies the client validation mode and the trust config resource to usewhen validating client certificates. When the client presents an invalidcertificate or no certificate to the load balancer, theclient validationmode specifies how the client connection ishandled. You can specify all the mTLS authentication related parameters inthe server TLS policies. The Client Authentication(ServerTLSPolicy) resource is attached to the target HTTPS proxy resource.

The following diagrams show the different mTLS components attached to the targetHTTPS proxy resource of global and regional Application Load Balancers.

global

The following diagram shows the components of an external Application Load Balancer deployment.This architecture also applies to the cross-region internal Application Load Balancer, which is aninternal Application Load Balancer that uses global components.

regional

The following diagram shows the components of a regional internal Application Load Balancerdeployment. This architecture also applies to the regional external Application Load Balancer,which is an external Application Load Balancer that uses regional components.

Client validation mode

When the client presents an invalid certificate or no certificate tothe load balancer, theclientValidationModeattribute on the Client Authentication(ServerTLSPolicy) resource specifies how the load balancer handles the client connection.

The values of the client validation mode are as follows:

• ALLOW_INVALID_OR_MISSING_CLIENT_CERT. Allows the connection from the clienteven if the validation of the client certificate failed or noclient certificate was presented. In this mode, the load balancerallows the connection from the client and passes all requests to the backendregardless of whether or not a chain of trust can be established.

  The proof of possession of the private key is always checked when the clientcertificate is presented. If the client cannot prove the possession of theprivate key, the TLS handshake is terminated even if the client validationmode allows invalid or a missing client certificate.

• REJECT_INVALID. Rejects the connection if a client does not provide acertificate or if the certificate validation failed. In this mode, the load balancer terminates the connectionfrom the client if it cannot establish a chain of trust from the clientcertificate back to the trust anchor.

Configure mTLS on the load balancer

The following is a high-level overview of the key steps that you need to follow toconfigure mTLS on your load balancer:

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

2. Link the trust config to the Client Authentication(ServerTLSPolicy) resource, which defines the client validation mode ofeitherALLOW_INVALID_OR_MISSING_CLIENT_CERT orREJECT_INVALID.

3. Attach the Client Authentication (ServerTLSPolicy) resource tothe target HTTPS proxy resource of the load balancer.

4. Optional: You can use custom mTLS headers topass information about the mTLS connection to a backend service or a URLmap.

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

• Set up mutual TLS with user-provided certificates
• Set up mutual TLS with a private CA

Client certificate validation steps

When validating the client certificate, the load balancer does the following:

1. Verify that the client possesses the private key.

   The client proves possession of the private key associated with the publickey in the certificate by generating a signature during the handshakeprocess. The load balancer verifies this signature using the client's publickey. If the signature verification fails, it means that the client is notthe owner of the certificate, in which case, the TLS handshake is terminatedeven if your configuration allows invalid or a missing client certificate.No errors are logged for global external Application Load Balancers, but a TLS error is loggedin theproxyStatus field for regional external Application Load Balancers and internal Application Load Balancers.

2. Verify the chain of trust.

   The load balancer verifies the chain of trust between the client certificateand the configured trust config. The verification checks include thefollowing:

   • The client, intermediate, and root certificates comply with thecertificate requirements.
   • The subject field in the parent certificate matches the issuer field in the child certificate. This verification ensures that the parent certificate's identity (subject) is the same as the identity listed as the issuer in the child certificate.
   • 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.
   • The subject alternative name (SAN) of a child certificate does not violate theNameConstraints field in the parent certificate.
   Note: Self-signed client certificates fail to form a valid chain of trust and are always rejected.

3. Forward the request to the backend.

   If the client certificate validation succeeds, the request is forwarded tothe backend usingcustom mTLS headers.

   However, if the validation fails, the action taken depends on the value of theclient validation mode:

   • ALLOW_INVALID_OR_MISSING_CLIENT_CERT: The request is forwarded withcustom mTLS headers indicating the reason forvalidation failure. For cross-region internal Application Load Balancers, regional external Application Load Balancers,and regional internal Application Load Balancers, in addition to custom mTLS headers, you canconfigure mTLSoptionalfields tocheck the reason for the failure.

   • REJECT_INVALID: The connection is terminated and theerrors arelogged to Cloud Logging.

Custom mTLS headers passed to the backend

The following table shows thecustom mTLSheader variablesthat are available to be passed to the backend, both when the client certificatepasses validation and when it fails. If the client certificate fails validation,requests are passed to the backend only when the client validation mode is set toALLOW_INVALID_OR_MISSING_CLIENT_CERT.

These variables can also be set onURL map.

Parse custom header variable values passed to the backend

Somecustom mTLS header variable values areBase64-encoded string representations of binary Distinguished Encoding Rules(DER) certificate data. You can decode Base64-encoded strings using your choiceof tools or software libraries. The following are some examples:

• macOS and Linux systems can use the command-linebase64 tool, which is acore utility included in both operating systems. To decode Base64-encodedstrings using thebase64 utility, pass the encoded string as standardinput to thebase64 command and use the-d flag to decode the string asfollows:

  echoBASE_64_ENCODED_STRING | base64 -d

• Python includes thebase64 module, which can be used to decodeBase64-encoded strings as follows:

  import base64encoded_string=BASE_64_ENCODED_STRINGdecoded_string=base64.b64decode(encoded_string).decode()print(decoded_string) # Note that a newline character (\n) is added to the end of the string.

Error handling and logging

Application Load Balancers provide detailed logging capabilities that allow youto monitor client 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.

Logged errors inREJECT_INVALID mode

If the client certificate validation fails, and the client validation mode is set toREJECT_INVALID, the connection is terminated and the errors are logged to Cloud Logging. These errors are described in the following table.

Logged errors for closed connections

When the client validation mode is set to eitherALLOW_INVALID_OR_MISSING_CLIENT_CERT orREJECT_INVALID, certain errorsresult in closed connections and are logged to Cloud Logging. These errorsare described in the following table.

If logging is enabled on the backend service, you canview logged errors forclosed connections during mTLS client certificatevalidation.

Limitations

• The load balancer doesn't perform revocation checks on client certificates.

• Application Load Balancers let you upload a trust config with a singletrust store, that contains at most: 200 of combined number of trust anchors andintermediate certificates (number of intermediate certificates is limited to100) and 500 certificates that are added to an allowlist.All intermediate certificates must not have more than three certificates thatshare the same Subject and Subject Public Key info. For more information, seeQuotas and limits.

• The maximum depth for a certificate chain is ten, including the root and clientcertificates. The maximum number of times that intermediate certificates can beevaluated when attempting to build the chain of trust is 100. For moreinformation, seeQuotas and limits.

• Keys of certificates uploaded and passed from the client are restricted tothe following:

  • RSA keys can range from 2048 to 4096 bits. For more information,seeQuotas and limits.
  • ECDSA keys can use the P-256 or P-384 curves.

• The accepted certificate chain received from the client is limited toup to 16 KB and 10 certificates. For more information, seeQuotas and limits.

• Root certificates used for validation cannot contain morethan 10 name constraints. For more information, seeQuotas and limits.

• The Layer 1Google Front Ends (GFEs)enforces a non-configurable timeout of 10 seconds for the client to presentits certificate during the TLS handshake. Under peak load, this timeout mightbe shorter. Clients must complete certificate presentation within thistimeframe to successfully establish an mTLS connection.

What's next

• Set up mutual TLS with user-provided certificates

• Set up mutual TLS with a private CA

• Variables that can appear in the header value