Client certificates (mTLS)
Standard TLS verifies the server's identity to the client. Mutual TLS (mTLS) adds a second check: the server also verifies the client's identity using a client certificate. This allows you to restrict access to devices or services that present a valid certificate.
Use Cloudflare's public key infrastructure (PKI) to create client certificates, or bring your own CA (BYOCA).
Mutual TLS (mTLS) authentication is a common security practice that uses client certificates to ensure traffic between client and server is bidirectionally secure and trusted. mTLS also allows requests that do not authenticate via an identity provider — such as Internet-of-things (IoT) devices — to demonstrate they can reach a given resource.
When a hostname has mTLS enabled, Cloudflare requires connecting clients to present a valid certificate. Client certificates are installed on the devices or services that should be granted access.
Cloudflare validates client certificates against CAs set at the account level. Because validation is account-level, the same certificates work across multiple domains under your account, as long as mTLS is enabled for each hostname (for example, host.example.com, name.example.net, secure.anotherdomain.test).
The account-level CAs can be:
- The Cloudflare-managed CA: This is the default option. Certificates and hostname associations are listed on the Cloudflare-issued tab of the Client Certificates dashboard ↗.
- BYOCA certificates: Available on Enterprise accounts. Certificates and hostname associations are listed on the BYOCA tab of the Client Certificates dashboard ↗.
Cloudflare then stores the validation result in a field called cf.tls_client_auth.cert_verified:
- Success:
cf.tls_client_auth.cert_verifiedistrue, and you can find client certificate details in specific mTLS fields. - Failure:
cf.tls_client_auth.cert_verifiedisfalse.
mTLS supports several implementation patterns depending on what you are protecting. For a broader overview, refer to the mTLS learning path.
- Application security — restrict access to your web application based on client certificates
- mTLS for Zero Trust — authenticate users and services through Cloudflare Access
- mTLS with API Shield — validate API clients with certificate-based authentication
- mTLS Workers binding — present a client certificate when your Worker connects to an external service
Apart from the mTLS Workers binding, any of the above implementations can use your own CA instead of the Cloudflare-managed one. Refer to Bring your own CA.
Use the mTLS Workers binding when you need your worker to present a client certificate to an external service. To authenticate requests from a client to your worker instead, refer to the regular mTLS for application security implementation.
flowchart LR
accTitle: mTLS from client to worker versus mTLS from worker to external service
accDescr: Diagram showing two different implementations that can be considered for mTLS with Cloudflare Workers.
A[Client] <--App security mTLS--> B((Cloudflare))<--mTLS worker binding--> C[(External service)]