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. |