Keep Access client-certificate trust separate from the website server certificate

The CA uploaded for Access mTLS validates clients, not the certificate shown by the website.

Source facts

Cloudflare Access mTLS uses an uploaded certificate authority to validate client certificates. The documentation states that this certificate does not control the server certificate presented to browsers. For a client certificate issued through an intermediate CA, the required upload includes the intermediate and root chain; server TLS certificates do not belong in that upload. Policies can match any valid certificate from the configured CA or a specific common name. The protected hostname must also be associated with the uploaded authority.

Source: Cloudflare — Access mTLS.

Applicability

This covers Access mTLS and Service Auth, whose plan availability differs from zone-level mTLS. Check the account’s supported feature set and the client’s certificate-storage behavior before implementation.

DSE recommendation

DSE recommends maintaining separate records for website server certificates, client certificates, and client-issuing CAs. Record the approved hostname and intended client population with the Access policy. Choose a broad valid-certificate selector only if every client issued by that CA is meant to qualify; otherwise review a more specific design. Protect client private keys and define issuance, renewal, and retirement procedures. Troubleshoot server trust errors independently from client-certificate rejection so an unrelated certificate change does not expand access.

Verification

Use a test hostname to compare an intended client certificate, no client certificate, and a certificate outside the approved population. Confirm the browser’s server-certificate validation still succeeds normally. Review the matched hostname and policy, and remove test client credentials from temporary files afterward.

Official reference

Cloudflare — Access mTLS. Reviewed October 15, 2026.