TLS and mTLS connection with GCP Application Load Balancer

The GCP Application Load Balancer is a layer 7 load balancer that is commonly used to implement HTTPS communication. The authentication in this case is one-way, meaning that the client verifies the identity of the server.

In addition, GCP Application Load balancer can utilize mutual TLS (mTLS) to verify the identity of clients that connect to it. During the TLS handshake, the mTLS connection at the load balancer requests the client to send a certificate and authenticate itself. This helps to ensure that only trusted clients communicate with the load balancer’s backend applications. The GCP Application Load Balancer supports frontend mTLS, which terminates the mTLS connection at the load balancer itself and performs client certificate validation at the load balancer frontend.

mTLS with GCP Application Load Balancer

The following are the GCP resources that must be configured to implement the mTLS setup with GCP Application Load Balancer:

1. ServerTlsPolicy
   Server TLS policies is attached to the target HTTPS proxy resource of the load balancer. This resource allows the server-side TLS mode and the TrustConfig resource to use when validating client certificates.
2. Trust Config
   This is a Certificate Manager resource. TrustConfig contains a single trust store resource that is used to validate client certificates.
3. Trust Store
   This contains the trust anchor and intermediate certificate authority (CA) certificates that are used to validate the client certificate chain.

The GCP Application Load Balancer frontend mTLS architecture overview is covered in detail here.

This article will describe the detailed steps necessary to generate self-signed certificates and configure a GCP Application Load Balancer to accept a strict mutual TLS (mTLS) connection.

Certificates used for the mTLS configurations must be generated with the certificate requirements outlined here. The following steps detail how to generate sample certificates that adhere to the certificate requirements:

1. Create root certificate:

# Create root.conf:
cat << EOF > root.conf
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements
prompt                    = no

[extension_requirements]
basicConstraints          = critical,CA:TRUE
keyUsage                  = keyCertSign

[dn_requirements]
countryName               = IN
stateOrProvinceName       = Telangana
localityName              = Hyderabad
0.organizationName        = Google
organizationalUnitName    = IT
commonName                = root
EOF

# Generate the root certificate using the root.conf file:
openssl req -x509 \
-new -sha256 -newkey rsa:2048 -nodes \
-days 3650 \
-config root.conf \
-extensions extension_requirements \
-keyout root.key -out root.cert

2. Create csr for intermediate certificate 1

# Create int.conf
cat << EOF > int.conf
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements
prompt                    = no

[extension_requirements]
basicConstraints          = critical,CA:TRUE
keyUsage                  = keyCertSign

[dn_requirements]
countryName               = IN
stateOrProvinceName       = Telangana
localityName              = Hyderabad
0.organizationName        = Google
organizationalUnitName    = IT
commonName                = int
EOF

# Create csr for first intermediate certificate with the int.conf file: 
openssl req \
-new -sha256 -newkey rsa:2048 -nodes \
-config int.conf \
-extensions extension_requirements \
-keyout int.key -out int.req

3. Create intermediate certificate 1

openssl x509 -req \
-CAkey root.key -CA root.cert \
-set_serial 1 \
-days 3650 \
-extfile int.conf \
-extensions extension_requirements \
-in int.req -out int.cert

4. Create csr for intermediate certificate 2

# Create int2.conf file:
cat << EOF > int2.conf
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements
prompt                    = no

[extension_requirements]
basicConstraints          = critical,CA:TRUE
keyUsage                  = keyCertSign

[dn_requirements]
countryName               = IN
stateOrProvinceName       = Telangana
localityName              = Hyderabad
0.organizationName        = Google
organizationalUnitName    = IT
commonName                = int2
EOF

# Generate the csr for a second intermediate certificate:
openssl req \
-new -sha256 -newkey rsa:2048 -nodes \
-config int2.conf \
-extensions extension_requirements \
-keyout int2.key -out int2.req

5. Create intermediate certificate 2

openssl x509 -req \
-CAkey int.key -CA int.cert \
-set_serial 1 \
-days 3650 \
-extfile int2.conf \
-extensions extension_requirements \
-in int2.req -out int2.cert

6. Generate server certificates:

# Create server.conf file:
cat << EOF > server.conf
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements
prompt                    = no

[extension_requirements]
basicConstraints          = CA:FALSE
keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage          = serverAuth,clientAuth
subjectAltName            = DNS:test-domain.com,DNS:www.test-domain.com

[dn_requirements]
countryName               = IN
stateOrProvinceName       = Telangana
localityName              = Hyderabad
0.organizationName        = Google
organizationalUnitName    = DEV
commonName                = test-domain.com
EOF

# Generate the CSR for creating a server certificate:
openssl req -new -keyout server.key -out server.csr -config server.conf

# Generate the Server Certificate:
openssl x509 -req -in server.csr -out server.cert \
 -extfile server.conf -extensions extension_requirements \
 -days 365 -CA int2.cert -CAkey int2.key

7. Generate client certificate:

# Create client.conf
cat << EOF > client.conf
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements
prompt                    = no

[extension_requirements]
basicConstraints          = CA:FALSE
keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage          = serverAuth,clientAuth
subjectAltName            = DNS:test-client.com,DNS:www.test-client.com

[dn_requirements]
countryName               = IN
stateOrProvinceName       = Telangana
localityName              = Hyderabad
0.organizationName        = Google
organizationalUnitName    = QA
commonName                = test-client
EOF

# Generate CSR for client certificate:
openssl req -new -keyout client.key -out client.csr -config client.conf

# Generate the client certificates:
openssl x509 -req -in client.csr -out client.cert \
 -extfile client.conf -extensions extension_requirements \
 -days 365 -CA int2.cert -CAkey int2.key

8. Once all the certificates are generated, these certificates can be used to create the trust config and network security resources with the steps mentioned here.

9. In order to execute the strict mTLS mode, the server TLS policy must be created with the clientValidationMode key set to REJECT_INVALID. This will ensure that only requests that provide a client certificate that can be validated against a TrustConfig resource are passed to the backend.

10. It is also possible to configure mTLS custom headers for the load balancer with any of the headers listed here. Custom headers are passed to the backend when the clientValidationMode is set to ALLOW_INVALID_OR_MISSING_CLIENT_CERT or the client certificate successfully passes certificate validation.