---
schema_version: "1"
id: 8ac195d6b0bd6594985a413a0fa62d4db7d20ddfcf75680d6d9efa4b07f2682d
title: Enable Client Authentication
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/anypoint-security/enable-client-authentication.md
canonical_url: https://docs.mulesoft.com/anypoint-security/enable-client-authentication
source_site: docs.mulesoft.com
content_type: documentation
content_hash: b072fef9885d61dca80fce1755fac6dca16c847d79206fac0ae3a51b8b186ac8
description: MuleSoft Documentation Site
latest: true
---
---
product: Security
version: master
---

# Enable Client Authentication

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

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](https://docs.mulesoft.com/anypoint-security/configure-tls-context-rtf-lb)

- [Cipher Suites](https://docs.mulesoft.com/anypoint-security/cipher-suites)