Mutual TLS Authentication

Mutual TLS authentication (mTLS) through Cloudflare Access requires additional account permissions. If you are interested in enforcing mTLS authentication in your application with Access, please contact your Customer Success Manager.

Mutual TLS authentication ensures that traffic is both secure and trusted in both directions between a client and server. mTLS can be used for allowing requests that do not login with an identity provider, like IoT devices, to demonstrate that they can reach a given resource. Client certificate authentication can also be used as a second layer of security for team members who both login with an identity provider and present a valid client certificate.

Cloudflare Access can add mutual TLS authentication to your application. With a root certificate authority in place, Access will only allow requests from devices that have a corresponding client certificate. When a request is made to the application, Access will respond with a request for the client to present a certificate. If the device fails to present one, the request will not be allowed to proceed. If the client does have a certificate, Access will complete a key exchange to verify.

mTLS Diagram

Adding Mutual TLS Authentication to your Access Configuration

  1. To enforce mutual TLS authentication, navigate to the Access tab in the Cloudflare dashboard for the application you need to secure.
  2. In the Access panel, click Add A New Certificate in the “Mutual TLS Root Certificates” card.
  3. In the modal, assign the root certificate authority a name. Next, paste the root certificate authority certificate in the “Certificate content” field in PEM format. If you are using an intermediate certificate, in addition to the root, upload the entire chain here.
  4. You will need to associate the certificate with a hostname as paths cannot be associated. In the “Associated Hostnames” field, input the hostnames where you plan to enforce mutual TLS authentication. This must be hostnames in your account.
  5. Next, create an Access Policy. Apply the policy to the path you intend to protect.
  6. Under the Policies section, name the policy and select “Non Identity” as the Decision.
  7. Under “Include” select “Valid Certificate” in the drop-down and it will populate with the certificate you associated with this hostname.
  8. Save the rule; you can use cURL to test the operation.

Testing with cURL

For example, if your site is example.com and you’ve set up an Access policy on https://auth.example.com using mTLS, start by attempting to cURL the site without a client certificate:

curl -sv https://auth.example.com

You should receive a 403 forbidden response if the client certificate isn’t provided, preventing site access.

Now, add your client certificate information to the request:

curl -sv https://auth.example.com --cert example.pem --key key.pem

If authenticated correctly you should see a CF_Authorization Set-Cookie header returned with a response through Cloudflare.

Method of Validation

Cloudflare Access evaluates every request to your application based on rules you configure. Client certificates provide a method to authenticate requests where an identity provider is not used, like IoT devices. Additionally, when an identity provider is used, enforcing mutual TLS authentication adds a second layer of security to control who can reach your application.

Note: If a request is made without a valid client certificate, the failure will return a 403 Forbidden response.

  1. With a policy in place, Access will evaluate all requests to the origin for the presence of a valid client certificate. When the client devices sends the client “hello”, Cloudflare Access will respond with the server “hello” and a request for the client certificate.
  2. The client certificate, if configured on the device, will be presented with the request from Cloudflare for a client certificate.
  3. Cloudflare Access will proceed to complete the client authentication handshake against the root certificate authority and, if applicable, intermediates configured for the policy.
  4. Chain verification can be used for certificate validation. If a chain is used, Access will evaluate each certificate in the chain to ensure none are expired.
  5. If the client certificate is trusted by the root certificate, Cloudflare Access will allow the request and subsequent requests to proceed by generating a signed JSON Web Token for the client.

Passing Request Headers

Cloudflare makes client certificate details available to be passed as request headers to your origin. For more information, follow the instructions here.

Session Duration Settings

By default, Cloudflare Access will generate and sign a JSON Web Token (JWT) for all requests that complete a successful mutual TLS handshake. The token is valid for the session duration configured in the Access policy. Teams can configure automated services to reuse that token on subsequent requests. When mutual TLS is a component of users authenticating to a service, this removes the burden of an individual completing the client certificate prompt in their browser on each request.

In some cases, particularly IoT examples, the expected behavior is that Access will force a new mutual TLS handshake on each request. In those cases, the token is not needed and teams may need to ensure it expires immediately to remove the risk of it being reused. To enable this in Access, set the session duration in the policy modal to “No Duration” - Cloudflare will still generate a token, but that token will only be valid for the lifecycle of an individual request. Additionally, the token will not be sent in the response.