Configure mTLS
When you specify API hosts in mTLS authentication, Cloudflare will block all requests that do not have a client certificate for mTLS authentication.
Before you can protect your API or web application with mTLS rules, you need to:
- Check that the certificate installed on your origin server matches the hostname of the client certificate, for example
api.example.com
. Origin server wildcard certificates such as*.example.com
are not supported. - Create a client certificate.
- Configure your mobile app or IoT device to use your Cloudflare-issued client certificate.
- Enable mutual Transport Layer Security (mTLS) for a host in your zone.
- Log in to the Cloudflare dashboard ↗ and select your account and domain.
- Go to SSL/TLS > Client Certificates.
- Select Create a mTLS rule.
- In Custom rules, several rule parameters have already been filled in. Enter the URI path you want to protect in Value.
- (Optional) Add a
Hostname
field and enter the mTLS-enabled hostnames you wish to protect in Value. - In Choose action, select
Block
. - Select Deploy to make the rule active.
Once you have deployed your mTLS rule, any requests without a valid client certificate will be blocked.
To review your mTLS rule in the Expression Builder, select the wrench icon associated with your rule.
In the Expression Preview, your mTLS rule includes a compound expression formed from two simple expressions joined by the and
operator.
The first expression — not cf.tls_client_auth.cert_verified
— returns true
when a request to access your API or web application does not present a valid client certificate.
The second expression uses the http.request.uri.path
field, combined with the in
operator, to capture the URI paths your mTLS rule applies to.
Because the action for your rule is Block, only requests that present a valid client certificate can access the specified hosts.
For enhanced security, Cloudflare recommends that you validate the SHA-256 certificate hash alongside the verified certificate field. This ensures that only requests presenting a valid client certificate with a specific fingerprint are allowed.
You can implement this by using an expression similar to the following:
not (cf.tls_client_auth.cert_verified and cf.tls_client_auth.cert_fingerprint_sha256 eq "253E08C1AB67EB7630C61734D377D75D5DCCDE2F6E69986C221D66E848B64321")
To obtain the SHA-256 fingerprint of a client certificate stored in the mtls.crt
file, you can run the following OpenSSL command:
openssl x509 -noout -fingerprint -sha256 -inform pem -in mtls.crt | cut -d "=" -f 2 | tr -d ':'
253E08C1AB67EB7630C61734D377D75D5DCCDE2F6E69986C221D66E848B64321
To check for revoked client certificates, you can either add a new mTLS rule or add a new expression to the default rule. To check for revoked certificates, you must use the Expression Builder.
When a request includes a revoked certificate, the cf.tls_client_auth.cert_revoked
field is set to true
. If you combined this with the default mTLS rule, it would look similar to the following:
((not cf.tls_client_auth.cert_verified or cf.tls_client_auth.cert_revoked) and http.request.uri.path in {"/admin"})