Advantages of client authentication with Mutual TLS on Google Cloud Load Balancing

With the help of External HTTPS Load Balancing, you can now outsource client certificate authentication thanks to the Preview of front-end mutual TLS (mTLS) support that we are delighted to introduce. With TLS offload, the load balancer displays a certificate on the server’s behalf, which the client uses to confirm the identity of the server. The load balancer may now obtain a certificate from the client and use that to confirm the client’s identity thanks to frontend mTLS offload.

Uses

1. mTLS support can assist customers in adhering to regulatory standards like OpenBanking, which call for apps to need the load balancer to verify the identity of clients connecting to it.

2. Clients can construct distinct value-added security services using mTLS on top of mutual TLS authentication foundations.

3. To verify their devices when they call into services housed on Google Cloud behind the global load balancer, IoT and industrial clients can utilise mutual TLS.

4. Authentication for Apigee X Northbound traffic using mTLS clients is now supported by the global external HTTPS Load Balancer.

5. Google security tools like Identity Aware Proxy are made possible by mTLS to impose client certificate-based access restriction for apps hosted on Google.

Mutual TLS Configuring

In order to set up mutual TLS on global external HTTP(S) load balancing, you must establish the trust settings necessary for client cert authentication, as well as how the load balancer should authenticate incoming connections. You mention:

• A server TLS policy that instructs the load balancer how to handle a failed certificate validation and authenticate incoming requests.

• A trust configuration that describes a chain of trust that the load balancer employs to authenticate client certificates using Certificate Manager resources. This enables you to employ client certificates created by users, certificates issued by private Certificate Authorities, or certificates provided by third-party Certificate Authorities of your choice.

Features

Following certificate verification, the load balancer can provide the following data to the backend as custom request headers:

If the certificate passes trust chain validation, some well-known fields such as certificate serial number, SANS, etc., will be displayed, along with the validation result and any validation failures.

What will be next ? 

Our shared TLS adventure is just getting begun. Along with other desired enhancements, we will shortly be expanding this functionality to regional internal and external load balancers.

We anticipate that these additional capabilities will make it easier for you to implement HTTPS and provide your clients with a more scalable and secure service.