Enable Client Authentication | MuleSoft Documentation
# Enable Client Authentication
If you choose a target value of **Anypoint Security** when adding your TLS context, you can optionally enable client authentication. TLS-enabled clients verify that they trust the server by validating the public certificate against their own set of trusted certificates.
A truststore to store certificates trusted by the client is required if you are enabling client authentication for the TLS context.
To enable client authentication:
  1. In the Create TLS Context page for the secrets group, select **Enable Client Authentication** and provide the following information:
     * **Verification Depth** Select the maximum depth to allow for the certificate chain verification.
     * **Revocation Method**
     * **Send Trust Store** Select this option if you want the inbound load balancer to send the truststore to the far-end client for mutual TLS. Clients use the truststore to select the correct certificate and path to use in cases where a client has multiple certificates and paths provisioned.
     * **Perform Certificate Pinning** Select this option if you want to allow access only for client certificates that are present in the selected certificate pinning list. In this case, a client certificate must have a chain of trust to a certificate (usually a CA) that appears in the truststore but also must be explicitly present (pinned) in the selected certificate pinning list.
  2. Click **Advanced Options** to expand the available options, and select the options to enable:
     * **Certificate Checking Strength** This option allows the application to control whether strict or lax certificate checking is performed during chain-of-trust processing.
Lax certificate checking offers more flexibility because of its less rigorous verification process, but it comes with a higher risk of accepting potentially compromised or fraudulent certificates. Strict certificate checking has more rigorous requirements for certificate validity and revocation checking, which demands more computational resources.
     * **Certificate Policy Checking** Controls certificate policy processing as defined in RFC 3280 and 5280. A certificate can contain zero or more policies. A policy is represented as an object identifier (OID). In an end-entity certificate, this policy information indicates the policy under which the certificate has been issued and the purposes for which the certificate can be used. In a CA certificate, this policy information limits the set of policies for certification paths that include this certificate. Applications with specific policy requirements are expected to have a list of those policies that they will accept and to compare the policy OIDs in the certificate to that list. If this extension is critical, the path validation software must be able to interpret this extension (including the optional qualifier), or must reject the certificate.
     * **OID** Select the object identifier options, which include:
       * **Require Initial Explicit Policy** Indicates that the path must be valid for at least one of the certificate policies in the `user-initial-policy-set`.
       * **Certificate Policies** At minimum, consists of a policy identifier (OID).
     * **Authentication Overrides** Select the criteria for when to override failing authentication when mutual authentication is performed.
  3. Click **Save**.


## See Also
  * Configure a TLS Context for Runtime Fabric Load Balancer
  *