mTLS client validation modes

[mountaincode2]

In the "first step of certification validation " , we are saying that the TLS handshake is terminated even if the configuration allows invalid or missing client certificates. But the same configuration mode content in the "MTLS client validation modes" section  says that the connection is allowed even if the certificate chain validation of the client certificate failed or no client certificate was presented.

First step of the client certification validation

https://cloud.google.com/load-balancing/docs/mtls#validation-steps

If this step fails, the load balancer always fails the TLS handshake, even if your configuration allows invalid or missing client certificates, and no information is logged for global external Application Load Balancers, but a TLS error is logged in the proxyStatus field for regional external Application Load Balancers and internal Application Load Balancers.

MTLS client validation modes section

https://cloud.google.com/load-balancing/docs/mtls#mtls_errors

ALLOW_INVALID_OR_MISSING_CLIENT_CERT allows the connection from the client even if certificate chain validation of the client certificate failed or no client certificate was presented. The proof of possession of the private key is always checked when the client certificate is presented.

----

So in https://cloud.google.com/load-balancing/docs/mtls#validation-steps, it says:

> If this step fails, the load balancer always fails the TLS handshake, even if your configuration allows invalid or missing client certificates...

But then the latter seems to be at odds with the description of `ALLOW_INVALID_OR_MISSING_CLIENT_CERT`, which says that:

allows the connection from the client even if certificate chain validation of the client certificate failed or no client certificate was presented.

[mountaincode2]

Can anyone help me with this.

Thank you!

[jamespatrickm]

Hi @mountaincode2,

I believe the first step of validation specifically addresses the TLS handshake's termination under certain conditions. On the other hand, `ALLOW_INVALID_OR_MISSING_CLIENT_CERT` setting applies to different stages of validation.

For example, let’s say a scenario wherein the handshake fails due to the first step, it doesn't matter if your configuration allows for invalid or missing certificates–the handshake will terminate. 

Now, in a scenario where the first step is passed, `ALLOW_INVALID_OR_MISSING_CLIENT_CERT` can indeed permit connections despite further validation issues.

I hope the information above is helpful.

[mountaincode2]

Hi @jamespatrickm :

So in the first step of the client validation, we are essentially verifying that the client can prove possession of the private key. In other words, we are verifying the "chain of trust". But both steps 1 and step 4 seem at odds with each other.

if the verification fails, that is, the client cannot prove the ownership of the private key, and If ClientValidationMode is set to ALLOW_INVALID_OR_MISSING_CLIENT_CERTIFICATE,why should the load balancer fail the TLS handshake.

PS:

Am i mistaken to understand that Step 1 is about verifying chain of trust? Whereas it is about verifying that the client possesses the private key corresponding to the presented certificate. And the subsequent steps are about verifying the chain of trust?