Use mTLS with Cloudflare protected resources

In this implementation guide we will be focusing on the L7 / Application Layer security for HTTP/S requests targeting proxied hostnames, including the first connection between client and Cloudflare.

Some common mTLS use cases are:

• Protect and verify legitimate API traffic by verifying Client Certificates provided during TLS/SSL handshakes.
• Check IoT devices' identity by verifying Client Certificates they provide during TLS/SSL handshakes.

There are two main ways to use mTLS at Cloudflare, either by using the Application Security offering (optionally including API Shield) or Cloudflare Access. Below is a non-exhaustive overview table of their differences:

Feature	Application Security (Client Certificate + WAF)	Cloudflare Access (mTLS)
Mainly used for	External Authentication (that is, APIs)	Internal Authentication (that is, employees)
Availability	By default, 100 Client Certificates per Zone are included for free. For more certificates or API Shield features, contact your account team.	Zero Trust Enterprise only feature.
Certificate Authority (CA)	Cloudflare-managed or customer-uploaded (BYO CA). There's a soft-limit of up to five customer-uploaded CAs.	Customer-uploaded only (BYO CA). There's a soft-limit of up to 50 CAs.
Client Certificate Details	Forwarded to the origin server via Cloudflare API, Cloudflare Workers, and Managed Transforms.	Forwarded to the origin server via Cloudflare API, Cloudflare Workers, and Managed Transforms. Client Certificate headers and Cf-Access-Jwt-Assertion JWT header can be forwarded to the origin server.
Client Certificates Revocation	Use the WAF Custom Rules to check for cf.tls_client_auth.cert_revoked, which only applies to Cloudflare-managed CA. For BYO CAs, it would be the same approach as with Cloudflare Access.	Generate a Certificate Revocation List (CRL) and enforce the revocation in a Cloudflare Worker.