Cloudflare Gateway Selective Decryption: SSL Inspection Configuration Guide for Enterprise Teams

When TLS decryption is enabled in Cloudflare Gateway, every HTTPS request from a WARP-enrolled endpoint routes through Cloudflare's network before reaching the destination server. Gateway terminates the TLS session on the Cloudflare side, applies your HTTP filtering policies to the decrypted request and response, then establishes a new TLS session to the origin. The certificate presented to the user's browser is signed by the Cloudflare root CA your organization has installed on managed endpoints. This forward proxy architecture is the same model used by enterprise SSL inspection appliances, but running at Cloudflare's global network scale rather than on-premises hardware. The critical dependency is the root CA certificate. Without it installed in the operating system and browser trust stores on every endpoint, users will see certificate errors on every inspected HTTPS site. WARP client handles this automatically on enrolled devices by installing the Cloudflare certificate during onboarding. For non-WARP managed endpoints, the certificate must be deployed via MDM tools like Microsoft Intune or Jamf before SSL inspection is enabled. This is a common deployment oversight that causes widespread browser errors when teams enable inspection before confirming certificate deployment coverage. As part of your zero trust architecture, Gateway SSL inspection enforces the principle that no traffic should be implicitly trusted simply because it is encrypted.

Cloudflare Gateway Do Not Inspect rules support multiple filtering dimensions that can be combined to build precise bypass policies. Each dimension targets a different aspect of the HTTP request, giving teams the flexibility to exclude exactly the traffic that should remain private without opening broad gaps in inspection coverage. The available dimensions are: destination domain or URL, where wildcard rules such as *.bankofamerica.com or .epic.com match all subdomains of a target; HTTP method, where you can bypass inspection specifically for POST requests to certain endpoints to avoid intercepting form submissions or API payloads that contain credential or payment data; URI path, where rules like /api/payments/ or /oauth/token exclude specific paths on otherwise-inspectable domains; Cloudflare application category, where the built-in app catalog includes categories such as Financial and Banking, Healthcare, and Legal that allow you to bypass entire market verticals without listing individual domains; and user identity or group, where rules scoped to Azure AD or Okta groups allow you to exclude sensitive roles such as executives, legal teams, or HR from decryption entirely based on their IdP group membership. Combining these dimensions produces bypass policies that are specific enough to close unintended gaps while remaining maintainable as your application portfolio grows. The ZTNA control model applies here too: bypass rules should follow least-privilege logic, granting inspection exceptions only where there is a documented reason.

Do Not Inspect rules live under Settings > Gateway > SSL/TLS in the Cloudflare Zero Trust dashboard. Each rule is an HTTP policy with the action set to Do Not Inspect. Rule evaluation in Gateway follows a top-down precedence model where the first matching rule wins. Because Do Not Inspect is evaluated before all other HTTP filtering actions, any traffic that matches a bypass rule exits the inspection pipeline entirely and is passed through without content analysis. This means that bypass rules should be written with the same care as allow rules in a firewall: overly broad bypass patterns create visibility blind spots that attackers can exploit by routing exfiltration or command-and-control traffic through bypassed destinations. The recommended configuration approach is to start with Cloudflare's built-in Financial and Banking and Healthcare application categories as the first two Do Not Inspect rules, then add domain-specific wildcard rules for any internal applications or SaaS tools that fail under inspection. After those foundational rules are in place, layer in method-specific or path-specific rules for domains where only certain request types need to be excluded. For example, a rule matching POST requests to .salesforce.com/services/apexrest/ can exclude API write operations from inspection while still allowing GET requests to be inspected for policy compliance. Document every bypass rule with a justification comment in the rule name field so that future administrators can audit the policy without having to reconstruct the original reasoning.

Certificate pinning is the leading cause of application breakage when SSL inspection is first enabled. Applications that pin certificates validate the server certificate against a hardcoded fingerprint or public key embedded in the application binary. When Gateway's root CA issues a replacement certificate for an inspected session, the pinned application rejects it as untrusted and the connection fails. The most commonly affected enterprise applications are Microsoft Teams, Slack, Zoom, and many mobile applications. Cloudflare maintains an internal list of known pinning applications and applies automatic bypass for many of them, but this list is not exhaustive and may lag behind application updates. The safest approach is to add explicit Do Not Inspect rules for any application your users rely on that exhibits connection failures after inspection is enabled. Symptoms of a pinning failure include the application showing a generic connectivity error, login loops, or silent feature degradation where some functions work but others do not. Beyond pinning, other common failure modes include expired intermediate certificates in the Gateway trust chain after a certificate rotation that was not propagated to all endpoints, split-tunnel configurations that route some traffic outside the WARP tunnel and therefore outside inspection, and browser extensions or local proxy software that intercepts connections before they reach the WARP client. The WAF layer operates on inbound traffic to your applications, but Gateway SSL inspection operates on outbound user traffic, so the two policies do not directly conflict. However, teams managing both should verify that WAF rules on internal applications do not block the source IP ranges used by Cloudflare Gateway when traffic is routed through the proxy.

TLS decryption adds measurable latency because Gateway must perform two TLS handshakes per connection instead of one, plus the overhead of inspecting the decrypted payload against your HTTP policies. In practice, this overhead averages 3 to 5 percent on most enterprise networks, but can be higher for latency-sensitive applications or connections to distant origin servers. The traffic categories where decryption overhead is least justified and most disruptive are high-volume streaming media such as video conferencing and content delivery networks, operating system and software update services where the download integrity is already verified by application-layer signatures, and backup or cloud sync services where large file transfers are encrypted by the application before they even reach the TLS layer. Excluding these categories from inspection reduces total inspection volume without reducing the security value of the program, because the threat risk in these traffic categories is low compared to browser-based web traffic and SaaS application traffic where social engineering, credential harvesting, and data exfiltration are most commonly observed. The Cloudflare application catalog includes categories for Streaming Media, Software Updates, and File Sharing that can be used as Do Not Inspect targets for each of these use cases. Measuring the impact of your bypass rules on total inspection volume is possible through the Gateway Analytics dashboard, which shows the breakdown of inspected versus bypassed sessions by category over time.

The Cloudflare root CA certificate is the foundation of the entire SSL inspection program. Without it, every inspected HTTPS connection generates a certificate error in the user's browser and in any application that validates server certificates. WARP client handles certificate installation automatically when a device is enrolled via the Cloudflare Zero Trust dashboard: the certificate is added to the operating system trust store during the WARP onboarding flow, covering most browsers that inherit from the OS trust store. The exception is Firefox, which maintains its own certificate trust store and requires a separate policy to trust third-party root CAs. On managed Windows endpoints using Intune, the Cloudflare certificate can be distributed as a Trusted Certificate device configuration profile, targeting all users or specific device groups. On macOS endpoints managed by Jamf, the certificate is distributed as a Configuration Profile payload of type Certificate. For both MDM platforms, the certificate should be scoped to the same device groups that have WARP profiles deployed, so that inspection is enabled and the certificate is trusted simultaneously on the same set of devices. Deploying the certificate to endpoints before enabling inspection in Gateway is the safest sequencing: it prevents a window where inspection is active but the certificate is not yet trusted. After deployment, verify coverage by querying your MDM platform for compliance status on the certificate configuration profile before toggling inspection on in the Gateway dashboard.