What is SSL/TLS Inspection?
SSL/TLS Inspection decrypts TLS-encrypted traffic at a trusted intermediary, checks it for threats and data loss, then re-encrypts it before forwarding it on. Most web traffic is encrypted today, so without this check, malware, phishing and data loss would stay largely invisible. In Zscaler Internet Access (ZIA), inspection happens inline in the Zero Trust Exchange: decrypt, check, re-encrypt. For browsers and applications to trust the intermediary, a matching root certificate is deployed to endpoints. Policies control which destinations are inspected and which are exempt, for example banking or healthcare services.
SSL/TLS Inspection in detail
Technically, inspection works as a controlled intermediary. The client builds the TLS connection to the inspection point, which in turn connects to the destination. The inspection point issues the client a certificate signed by a root certificate deployed across the organisation, either the Zscaler root certificate or your own company CA. If a device or application is missing this root certificate in its certificate store, certificate warnings appear.
Not all traffic can be inspected in a meaningful way. Applications with certificate pinning accept only their expected certificate and break under inspection, so they need targeted exceptions. There are also deliberate exceptions for privacy reasons, typically for categories such as banking or healthcare. Every exception is also a blind spot: whatever is not decrypted cannot be checked for malicious code or data loss. The art lies in keeping a documented exception list as small as possible.
Why SSL/TLS Inspection matters in Zscaler operations
For support teams, SSL/TLS Inspection is one of the most common hidden causes: browser certificate warnings, applications that only fail on the corporate network or only with an active client, uploads blocked by a policy. Without visibility into inspection and policy status, these cases look like application faults. The key questions are: is the connection inspected, does an exception apply, and does the device trust the root certificate?
At governance level, inspection coverage is a security indicator: too many, or too broad, exceptions undermine sandboxing, antivirus and DLP. At the same time, data protection and co-determination rules require traceable justification for which categories are exempt and why. For evidence, for example under NIS2, you need to document what the inspection policy looks like, who changed it, and when.
Common sources of error
- Root certificate not fully deployed: individual devices or tools with their own certificate store (browsers, development environments) do not trust the inspection point and throw certificate errors.
- Certificate pinning overlooked: pinned apps fail under inspection. Without a maintained exception list, recurring faults appear that are hard to trace.
- Overly broad exceptions: permanently exempting entire domains or categories from inspection creates blind spots for malware and data loss.
- Privacy categories left unregulated: missing or undocumented exceptions for banking and healthcare services become a compliance risk.
SSL/TLS Inspection in practice: what CentaurNexus contributes
CentaurNexus helps at both ends. For individual cases, Connectivity Triage Map combines the ZDX chain with policy status and states the cause in plain language, for example whether a block or a certificate problem sits behind the fault. At configuration level, Policy Health Saga scores configuration health with a prioritised action plan and a PDF report for NIS2 and DORA evidence, so overly broad exceptions and gaps in the inspection policy stand out systematically, as a read-only analysis with no automatic rule changes. The helpdesk needs no Zscaler admin rights for this. For how users can identify a block or certificate warning themselves, see Zscaler self-service directly in the browser.
Related terms
Frequently asked questions about SSL/TLS Inspection
Most web traffic is TLS-encrypted today, including malware downloads, phishing sites and data exfiltration. Without decryption, antivirus, sandboxing and DLP see only metadata and cannot evaluate content. Inspection makes encrypted traffic checkable, which is what allows the other protection functions to work at all.
Zscaler Internet Access sits inline in the data stream: the connection is decrypted at the Zero Trust Exchange, inspected, and re-encrypted towards the destination. Zscaler presents the endpoint with a certificate signed by a root certificate deployed across the organisation. Policies control which destinations are inspected and which are exempt.
Common exceptions cover applications with certificate pinning that break under inspection, as well as privacy-sensitive categories such as banking or healthcare services. It is important to keep exceptions small, justified and documented, because every exempted connection is a blind spot for threat and data protection checks.
It can be, with documented exceptions for sensitive categories, transparent information for employees, and clear rules on who may view inspection data. In Germany, this includes works council co-determination. The specific approach should be agreed with your data protection officer and, where applicable, the works council. This article does not replace legal advice.
Typical signals: certificate warnings that only appear with an active client or on the corporate network, applications that fail exactly at connection setup, or errors that disappear after a targeted exception. It helps to check whether the connection is inspected, which policy applies, and whether the device trusts the root certificate.
- Zscaler Help Portal: ZIA documentation, help.zscaler.com/zia
- Zscaler Help Portal: About SSL Inspection - help.zscaler.com/zia/about-ssl-inspection
- BSI (Germany's Federal Office for Information Security): Technical Guideline TR-02102-2 “Use of Transport Layer Security (TLS)” - bsi.bund.de/.../BSI-TR-02102-2
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.