Introducing client authentication with Mutual TLS on Google Cloud Load Balancing

We are excited to announce the Preview of front-end mutual TLS (mTLS) support, allowing you  to offload client certificate authentication using External HTTPS Load Balancing. With TLS offload the load balancer presents a certificate on behalf of the server that the client uses to verify the server’s identity. Now with frontend mTLS offload, the load-balancer can additionally request a certificate from the client and use that to verify the client’s identity.

Use cases

mTLS support can help customers meet compliance requirements for regulatory standards, such as OpenBanking, where applications need the load balancer to authenticate the identity of clients that connect to it.

With mTLS, customers can build differentiated value-added security services on top of mutual TLS authentication foundations.

IoT and Industrial customers can use mutual TLS to authenticate their devices as they call into services hosted on Google Cloud behind the global load balancer. 

The global external HTTPS Load Balancer now has mTLS client support for Apigee X Northbound traffic authentication.

mTLS enables Google security solutions such as Identity Aware Proxy to enforce client certificate-based access control for applications hosted on Google.

Configuring mutual TLS 

To set up mutual TLS on global external HTTP(S) load balancing you configure how the load balancer should authenticate incoming connections, including the trust configuration required to authenticate client certs. You specify: 

A server TLS policy that tells the load balancer how it should authenticate incoming requests and handle a failed certificate validation.

A trust configuration, using Certificate Manager resources, that expresses a chain of trust that the load balancer uses to authenticate client certificates. This allows you to use client certificates issued by your choice of third-party Certificate Authority, certificates issued by private Certificate Authority, or user-generated certificates. 

Supported features

After certificate validation, the load balancer can provide the following information as custom request headers to the backend:

A fingerprint of the certificate 

Selected well-known fields such as certificate serial number, SANS, etc., if the certificate passes trust chain validation

The validation result and any validation errors

What’s next ? 

We are just getting started with our mutual TLS journey. We will soon be extending this support on regional internal and external load balancers in addition to additional requested features. 

We hope these new features will enable you to deploy HTTPS seamlessly and offer a more scalable and secure service to your customers.