Troubleshooting

If your query returns an error even after configuring and embedding a client SSL certificate, check the following settings.

Note

Before troubleshooting, disable VPNs and proxies. These can interfere with the mTLS handshake.

---

Check SSL/TLS handshake

On your terminal, use the following command to check whether an SSL/TLS connection can be established successfully between the client and the API endpoint.

curl --verbose --cert /path/to/certificate.pem --key /path/to/key.pem https://your-api-endpoint.com

If the SSL/TLS handshake cannot be completed, check whether the certificate and the private key are correct. If the handshake completes but requests are still blocked, confirm that Cloudflare is verifying the client certificate.

---

Check mTLS hosts

Check whether mTLS has been enabled for the correct host. The host should match the API endpoint that you want to protect.

---

Review mTLS rules

To review mTLS rules, consider the steps below. For further guidance refer to Custom rules.

1. In the Cloudflare dashboard, go to the Security rules page.

   Go to Security rules

2. On a specific rule, select Edit.

3. On that rule, check whether:

   • The Expression Preview is correct.

   • The hostname, if defined, matches your API endpoint. For example, for the API endpoint api.trackers.ninja/time, the rule should look like:

     (http.host in {"api.trackers.ninja"} and not cf.tls_client_auth.cert_verified)

4. To edit the rule, either use the user interface or select Edit expression.

---

Advanced debugging

You can use Cloudflare Workers to debug client certificate validation failures.

1. Create a Worker to debug print cf.properties:

   JavaScript

   export default {
     async fetch(request, env, ctx) {
       console.info({ message: JSON.stringify(request.cf, null, 2) });
       return new Response(JSON.stringify(request.cf, null, 2))
     }
   };

2. Associate the Worker with the hostname where mTLS is enabled using a Worker route or a Custom Domain.

3. Make requests to the hostname and/or path configured, with and without sending the mTLS client certificate.

4. View your logs on the Observability dashboard and compare the responses against the expected values listed below.

   Go to Observability

• Valid certificate

  "tlsClientAuth": {
    "certPresented": "1",
    "certVerified": "SUCCESS",
  },

• Invalid certificate (for example, self-signed certificates)

  "tlsClientAuth": {
    "certPresented": "1",
    "certVerified": "FAILED:self signed certificate",
  },

• No certificate

  "tlsClientAuth": {
    "certPresented": "0",
    "certVerified": "NONE",
  },