Custom trust anchors for Cloudflare Gateway

Cloudflare is introducing support for customer-provided root certificates in its Zero Trust platform. IT and security administrators can now upload their own certificates — rather than being required to use a Cloudflare-issued certificate — to apply HTTP, DNS, CASB, DLP, RBI, and other filtering policies. The option complements the existing workflow of installing Cloudflare's own certificate for traffic inspection and forward proxy controls, letting organizations choose the deployment path that best fits their environment.

Organizations may prefer custom certificates for several reasons. Some want to control exactly which trust anchors are distributed across their fleet. Others have already deployed custom certificates to devices, often binding user attributes to those certificates or scoping them to internal-only domains. For these teams, applying additional security controls on top of an existing deployment is faster than installing another root certificate.

Uploading and enabling a custom certificate

To use a custom certificate, administrators first upload their root certificate via the Cloudflare API:

curl -X POST "https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/mtls_certificates"\
    -H "X-Auth-Email: <EMAIL>" \
    -H "X-Auth-Key: <API_KEY>" \
    -H "Content-Type: application/json" \
    --data '{
        "name":"example_ca_cert",
        "certificates":"<ROOT_CERTIFICATE>",
        "private_key":"<PRIVATE_KEY>",
        "ca":true
        }'

The root certificate is stored across Cloudflare's secure servers, with protections designed to prevent unauthorized access. Once uploaded, each certificate receives a UUID identifier, such as 2458ce5a-0c35-4c7f-82c7-8e9487d3ff60. That UUID is then combined with the Zero Trust account ID to associate and enable the certificate for the account:

curl -X PUT "https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/gateway/configuration"\
    -H "X-Auth-Email: <EMAIL>" \
    -H "X-Auth-Key: <API_KEY>" \
    -H "Content-Type: application/json" \
    --data '{
        "settings":
        {
            "antivirus": {...},
            "block_page": {...},
            "custom_certificate":
            {
                "enabled": true,
                "id": "2458ce5a-0c35-4c7f-82c7-8e9487d3ff60"
            }
            "tls_decrypt": {...},
            "activity_log": {...},
            "browser_isolation": {...},
            "fips": {...},
        }
    }'

Propagation is fast — roughly one minute — after which all new HTTPS connections for the organization's users are secured with the custom certificate. Because the rollout applies only to new connections, there is no maintenance downtime when switching from a Cloudflare-provided certificate or from a previous custom certificate; existing sessions continue unaffected.

Sticking with Cloudflare's certificate

Organizations that prefer to offload certificate management can instead install Cloudflare's root certificate on devices. This remains the simpler path for supporting HTTP filtering policies, and installation can be automated during managed deployments of the Cloudflare device client (WARP), which is required for forward proxy traffic.

Administrators can install either a .pem or .crt file, depending on their OS and app requirements. Cloudflare's developer documentation covers the process across operating systems and applications.

Roadmap

Both approaches share the same objective: enabling traffic inspection to defend against malicious activity and enforce data protection controls. Cloudflare's stated priority is giving organizations the flexibility to reach that goal with minimal friction.

Over the coming quarters, Cloudflare plans to deliver a UI for uploading and managing user-side certificates and to refresh the HTTP policy builder so admins can define behavior for origins that do not present a certificate signed by a public CA.