What is an SSL Inspection Bypass?
An SSL Inspection Bypass is a targeted exception that keeps certain applications or domains out of SSL/TLS Inspection altogether. The most common reason is certificate pinning: applications that have the server certificate hard-coded do not accept the dynamically issued inspection certificate and drop the connection. The exception lets these connections pass through unencrypted, while the rest of the traffic keeps getting inspected. Used correctly, a bypass is a precision tool: scoped as narrowly as possible, with a documented reason and a regular check on whether it is still needed.
SSL Inspection Bypass in detail
With SSL Inspection active, Zscaler issues the client a certificate signed by the tenant's intermediate CA for every inspected connection. Browsers trust it as soon as the certificate is deployed to the trust store. Applications with certificate pinning, on the other hand, compare it against the hard-coded original and end the connection after the TLS handshake, often with a certificate error or no message at all. Zscaler maintains an official list of affected applications, from Adobe services to mobile apps.
For the exception, Zscaler's documentation names two routes: excluding the cloud application as a whole from inspection, or excluding individual domains through a dedicated URL category. It is worth distinguishing this from a full Zscaler bypass through a PAC file or app profile: the inspection exception stays inside the Zscaler data path and keeps URL filtering and other controls, while a full bypass leaves it entirely.
Why SSL Inspection Bypasses matter in Zscaler operations
Bypasses decide two things at once: availability and visibility. When a needed exception is missing, a business application stops working, and the helpdesk often looks for the cause in Wi-Fi, VPN or server status, when the actual break is down to pinning. Where there are too many exceptions instead, a growing blind spot builds up: traffic nobody checks for malicious code or data exfiltration any more.
In practice, bypasses accumulate quietly: one exception for a project, one for a test, one added on request. After two years, nobody remembers which of them are still needed. That is why every bypass needs an entry with a reason, a date and an owner, plus a fixed review cycle. That way, inspection coverage stays a deliberate state rather than an accidental by-product of ticket history.
Common sources of error
- Excluding whole domains or categories where individual hostnames would do: the exception ends up unnecessarily broad.
- A bypass instead of an inspection exception: a full bypass around Zscaler also takes URL filtering and policy with it, not just decryption.
- Exceptions without documentation: without a reason and a date, nobody can later decide whether the exception can go.
- Treating pinning cases as a network problem: the drop right after the handshake gets mistaken for a Wi-Fi or server issue, and the ticket goes in circles.
SSL Inspection Bypass in practice: what CentaurNexus contributes
Whether a particular URL genuinely bypasses Zscaler altogether or is merely excluded from decryption is a question CentaurNexus answers without guesswork. PAC-Lens reads the PAC file actually active in the tenant and shows, through a test URL, which line applies and whether traffic runs directly or through Zscaler. How a single address can be checked live using a test URL is shown in our roughly two-and-a-half-minute video on the PAC tester. Connectivity Triage Map then classifies whether a reported problem sits with the device, the network or a policy. That turns the question “why won't this app work?” into a documented finding instead of a guess. How users can check connection issues themselves in advance is shown in the article Zscaler self-service right in the browser.
Related terms
Frequently asked questions about SSL Inspection Bypass
Apps like this check whether the server certificate matches one that is hard-coded exactly. When SSL inspection is active, though, Zscaler issues the app a dynamically generated certificate from the intermediate CA instead. That does not match the hard-coded original, so the app drops the connection. Zscaler documents affected applications in an official list.
According to Zscaler's documentation, there are two ways: exclude the affected cloud application from SSL/TLS Inspection as a whole, or exclude individual domains through a dedicated URL category. What works best in practice is the narrowest route: only the domains that are actually needed, with a documented reason and date, so the exception stays reviewable later.
An SSL inspection exception still routes traffic through Zscaler, just unencrypted; URL filters and other controls continue to apply. A bypass in the PAC file or the app profile, by contrast, sends traffic around Zscaler completely. That is a considerably bigger intervention and should stay the rare, well-justified exception.
Every exception is a blind spot: content in excluded connections does not get checked for malicious code or data exfiltration. Taken individually and justified, that is defensible; what becomes dangerous is a slow build-up over years. That is why bypasses belong in an inventory, documented with a reason, and reviewed regularly for whether they are still needed.
A typical pattern: the website works fine in the browser, but the matching desktop or mobile app fails to connect or reports a certificate or connection error. The drop happens right after the TLS handshake. Checking Zscaler's official list of pinned applications, together with a look at the client logs, confirms the suspicion.
- Zscaler Help Portal: Certificate Pinning and SSL/TLS Inspection (incl. list of pinned applications) - help.zscaler.com
- Zscaler Help Portal: Understanding SSL/TLS Inspection - help.zscaler.com
Note: CentaurNexus is an independent product of SourcingBlox GmbH and not an offering of Zscaler, Inc. Product and brand names belong to their respective owners.