Without SSL Inspection enabled, ZIA can match which of these against an HTTPS request?

Correct answer: (b) Only the SNI (destination domain) — visible in the unencrypted TLS handshake. Path, body, headers, files are all encrypted and invisible to ZIA. Correct: (b). TLS encrypts everything after the handshake. The SNI in ClientHello is the one field sent in cleartext, which is why URL Filtering can still match by domain — but URL path, HTTP method, request body, response body, and file contents are all hidden until SSL Inspection terminates the TLS. (a) requires Inspection. (c) is encrypted. (d) the SNI is more useful than fingerprint matching.

You enabled SSL Inspection for the engineering test group. Suddenly every user gets a "NET::ERR_CERT_AUTHORITY_INVALID" warning on every HTTPS site. What did you forget?

Correct answer: (c) Distribute the Zscaler Root CA to the endpoint trust stores BEFORE enabling Inspection. Browsers reject the Zscaler-issued site certs because the issuing chain isn't trusted. Correct: (c). The Zscaler Root CA must be in the endpoint trust store before MITM works transparently. Without it, every Zscaler-signed cert is "untrusted issuer" and the browser blocks. Always distribute via MDM (Intune/Jamf/GPO) first, verify on test endpoints, then turn on Inspection. (a) wouldn't cause this exact error. (b)/(d) are unrelated.

You distributed the Zscaler Root CA via Intune to all Windows laptops. Chrome and Edge work fine. Firefox users complain every HTTPS site shows cert warnings. Why?

Correct answer: (a) Firefox maintains its own cert store, separate from the OS. Fix: push a Firefox enterprise policy enabling security.enterprise_roots.enabled=true so Firefox reads from the OS trust store. (Or push the cert to each Firefox profile directly.) Correct: (a). Firefox's independent cert store is a famous footgun. Always plan for Firefox separately when distributing CAs. The security.enterprise_roots.enabled=true preference makes Firefox read OS-trust additions. Push via Firefox enterprise policy file (autoconfig.js). (b)/(c)/(d) don't fix the root cause.

Slack desktop app fails to connect after SSL Inspection rollout. Web browsers work fine. What's the root cause and the right fix?

Correct answer: (c) Slack desktop historically pinned its cert (Electron switch dropped strict pinning in 2022, but legacy installs and some endpoints still misbehave under MITM) — it refuses to trust the Zscaler-issued cert. Fix: add Slack (or its API domains) to the SSL Inspection Bypass rule at Order 5, OR confirm via a fresh client install before assuming pinning is the cause. Correct: (c). Even though Slack dropped strict pinning when it shifted to Electron, legacy installs and certain API endpoints still misbehave under MITM. Add to bypass and verify with a fresh client. Always add common pinned apps (banking apps, Apple services, MS Authenticator, WhatsApp Desktop) on day 1. (a) doesn't change pinning behaviour. (b) wouldn't help — pinning ignores trust additions. (d) blocks legitimate work.

An attacker renames a malicious payload.exe to resume.pdf and uploads it as a "resume". Your File Type Control allows PDFs but blocks .exe. Will ZIA block it?

Correct answer: (d) Yes — if the rule has "Detect File Type by Content" enabled, ZIA reads the magic bytes (Windows PE starts with MZ ) and identifies it as an executable regardless of filename. Always enable content-based detection. Correct: (d). File Type Control with MIME-by-magic-bytes detection is exactly the defence against this attack. Windows PE binaries start with MZ (Mark Zbikowski's initials, original MS-DOS engineer) — that signature is unmistakable. ZIA reads it regardless of filename. Always turn on "Detect File Type by Content" — extension-only detection is bypassable in 5 seconds. (a)/(b) ignore content-based detection. (c) SSL Inspection is needed to even see the file content if it's HTTPS.

Compliance team asks: "are we MITMing customer banking traffic and seeing their account balances?" What's the correct policy?

Correct answer: (b) No — banking and healthcare categories are configured as Bypass in SSL Inspection (Do Not Inspect). For privacy + compliance reasons, ZIA passes those flows through with TLS intact. We can confirm by visiting the bank URL from a corporate laptop and viewing the cert issuer — it should be the bank's CA, not Zscaler. Correct: (b). Banking and healthcare are universal bypass categories — a privacy and (in many jurisdictions) legal requirement. Verify by checking cert issuer on the bank URL; should be the bank's CA, not Zscaler. (a) violates regulations like GLBA, HIPAA, GDPR. (c)/(d) are nonsense distractors.

User downloaded a password-protected ZIP file. AV scan can't read the encrypted archive. What is the actual ZIA Cloud Sandbox behavior?

Correct answer: (b) ZIA Cloud Sandbox does NOT brute-force archive passwords. When it encounters a password-protected archive, it either blocks outright OR (Advanced tier) prompts the user to provide the password for inspection. The "sandbox brute-forces passwords" claim is a myth — don't say this in an interview. Correct: (b). Wrong. ZIA Cloud Sandbox does NOT brute-force archive passwords. When it encounters a password-protected archive, it either blocks outright OR (Advanced tier) prompts the user to provide the password for inspection. Brute-forcing is a myth — don't say this in an interview. (a)/(c) are common-but-wrong distractors students cite. (d) is nonsense.

SSL Inspection rule order is critical. Which order is correct?

Correct answer: (a) Bypass-Banking-Pinned (Order 5) → Bypass-Executives (Order 10) → Inspect-All (Order 100). Bypass rules at top so they fire before the generic Inspect catches them. Correct: (a). Same first-match logic as URL Filtering. Bypass exceptions go ABOVE generic Inspect rules — otherwise the generic rule fires first and MITMs everything (breaking banking + pinned apps). (b) is the inverted broken order. (c)/(d) ignore ZIA's evaluation model.

You want to confirm SSL Inspection is actually working on a test endpoint. What's the cleanest test?

Correct answer: (c) Open https://github.com in the browser, click the lock icon, view certificate. Issuer should contain the substring "Zscaler" (exact CN varies by Sub-Cloud — zscalerone/two/three/beta/Compliance). Don't match the literal "Zscaler Intermediate CA" string. Conversely, opening your bank URL should show the bank's real CA — proving bypass works. Correct: (c). The cleanest validation — view the cert chain in any browser. Inspected sites show Zscaler in the chain; bypassed sites show the original public CA. Tells you both "inspect works" and "bypass works" in 5 seconds. (a)/(b)/(d) tell you nothing about SSL Inspection.

You're rolling out SSL Inspection to 4000 users next month. What's the safest sequencing?

Correct answer: (d) Distribute Zscaler Root CA via MDM to all endpoints first → verify on test endpoints with cert chain check → enable Inspection for one pilot group (engineering + sales — highest pinned-app usage) for 1 week → catch pinned-app failures → add to Bypass list → broaden rollout by tranches with daily review. Correct: (d). The production pattern — cert distribution + verification + pilot + tranche rollout. The pilot week catches 95% of pinned-app issues with minimum blast radius. (a) is a Monday-morning disaster. (c) leaves a 20-hour security gap. (b) is hostile to users + impractical at scale.

SSL Inspection & File Type Control — Batch 11 · Lesson 6

Why this lesson matters

Run any 5 minutes of tcpdump on a corporate gateway and you'll see almost everything is TLS — HTTPS, IMAPS, SMTPS, even QUIC. Without SSL Inspection, ZIA's view of an HTTPS request is limited to the TLS SNI (the destination domain). It cannot read the URL path, the HTTP method, headers, request body, response body, or attached files. Every advanced ZIA feature — DLP, malware scan, sandbox detonation, full URL Filtering — depends on SSL Inspection being on.

SSL Inspection also breaks things if you do it wrong. Banking apps pin their certificate; sandbox-detecting malware checks cert chains; some old apps use mutual TLS that breaks completely. Hence the second half of this lesson — exemptions and File Type Control as the safety net.

The TLS handshake — normal vs ZIA-inspected

In a normal HTTPS connection, your browser does a TLS handshake directly with the destination server (e.g. github.com). The server returns its cert, your browser validates the chain to a trusted Root CA in the OS store, and the session is established.

With SSL Inspection enabled, ZIA's PSE intercepts the handshake. The PSE is now a proxy in two directions: one TLS session to the user, one to the destination. To make this work transparently, ZIA generates a fresh certificate on the fly that mimics the destination — but signs it with the Zscaler intermediate CA. The user's browser validates that chain against the Zscaler Root CA which you must pre-install on every endpoint. Without the root in the trust store, every HTTPS site shows a certificate warning. Hence the deployment dependency.

SSL Inspection — ZIA as transparent MITM

Cert: github.com issued by Zscaler Intermediate CA 3. Validates Zscaler Root in OS trust store ✓ → key exchange → encrypted Leg A LEG B 4. PSE acts as client: ClientHello + SNI=github.com 5. ServerHello + Real github.com cert issued by public CA 6. PSE validates public CA ✓ → key exchange → encrypted Leg B Inside PSE: decrypt Leg A → SSMA inspect → re-encrypt to Leg B

Two completely separate TLS sessions. The browser trusts ZIA because the Zscaler Root CA is in its OS trust store. ZIA trusts the origin because it validates the public CA chain itself. Inside the PSE, the cleartext briefly exists for SSMA inspection — URL filter, malware scan, DLP — then is re-encrypted on Leg B.

The Zscaler Root CA — distribution is mandatory

If the Zscaler Root CA isn't in the user's OS trust store, every single HTTPS site shows a "Your connection is not private — NET::ERR_CERT_AUTHORITY_INVALID" warning. So distribution is not optional — it's the first thing you do before turning SSL Inspection on for a single user.

Distribute via your MDM / endpoint mgmt tool

Endpoint	Method	Cert location after install
Windows (domain-joined)	GPO → Computer Config → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities → Import the Zscaler Root .cer	Local Computer → Trusted Root Certification Authorities
Windows (Intune-managed)	Intune → Devices → Configuration Profiles → Trusted certificate → upload Zscaler Root .cer → assign to device group	Local Computer → Trusted Root Certification Authorities
macOS	Jamf → Configuration Profiles → Certificate payload → upload .cer → "Always Trust" policy	System keychain → Certificates (Always Trust for SSL)
iOS / iPadOS	MDM profile → Certificate payload → "Use as a trusted root"	Settings → General → About → Certificate Trust Settings (must be manually enabled by user — friction point)
Android (managed)	Intune / Workspace ONE → Certificate profile → CA category → push	Settings → Security → Trusted credentials (User tab)
Firefox (any OS)	Firefox uses its OWN cert store — separate from OS! Set `security.enterprise_roots.enabled=true` in `about:config` OR push via Firefox CCK to read from OS store	Firefox internal cert DB
Linux (servers / dev)	Copy .cer to `/usr/local/share/ca-certificates/` + `sudo update-ca-certificates`	System CA bundle

⚠Common Mistake — Firefox forgotten

Firefox uses its own cert store, independent of the OS. You can push the Zscaler Root via GPO/Intune and Chrome/Edge will work fine — but Firefox users keep seeing cert errors. Either enable security.enterprise_roots.enabled=true via a Firefox enterprise policy (firefox.cfg or autoconfig.js), or manually push the cert to each Firefox profile. This catches every team at least once.

Pinned applications — when SSL Inspection breaks the app

Some apps don't trust your custom Root CA — they ship with a hard-coded "I will only ever trust THIS specific cert" rule. This is called certificate pinning, and it's intentional. Banking apps pin so even a compromised root CA can't MITM the customer. SDK-based mobile apps (Facebook, Twitter, Instagram) pin so even a corporate proxy can't see their traffic.

When ZIA MITMs a pinned app, the app rejects the Zscaler-issued cert and refuses to connect. The user sees "cannot connect" or the app silently fails. Current (2026) pinners you must plan for:

Microsoft Authenticator — pins on token exchange endpoints
Apple iCloud services — pinned across iOS and macOS
Banking apps — almost all of them (HDFC, ICICI, SBI, Chase, BoA)
WhatsApp Desktop — pins for messaging endpoints
Microsoft Teams — call media uses UDP/SRTP (not TLS) — ZIA can't proxy it at all
Cisco Webex — cert-pinned media channels

Webex/Zoom/Teams media plane: These apps break under SSL Inspection not because of cert pinning but because their media (audio/video) uses UDP-based SRTP that ZIA can't proxy at all. Bypass the media subdomains (e.g. *.webex.com, *.zoom.us, *.teams.microsoft.com) — and use the Zscaler-published bypass templates for these vendors.

The fix: SSL Inspection exemption list

ZIA ships an actively-maintained list of known pinned apps (Recommended Bypass list). Enable it, then add any custom apps you discover in your environment. Exempted destinations skip Leg A's MITM and pass through with TLS preserved — but you lose all visibility into that traffic.

ZIA · SSL Inspection exemption configuration

Policy → SSL Inspection → SSL Inspection Policy → + Add Rule

  Order:         5  (high priority — runs before generic Inspect rule)
  Name:          Bypass-Pinned-Apps
  Action:        Do Not Inspect
  URL Categories: (none — using App list)
  Cloud Applications: Microsoft Teams (media), Cisco Webex, Apple iCloud,
                      Banking, Microsoft Authenticator, WhatsApp Desktop
  User-defined URLs: banking.hdfc.com,
                     authenticator-api.microsoft.com,
                     *.webex.com, *.teams.microsoft.com
  Action on inspection failure: Bypass (don't break the app)

Then add a default "Inspect everything else" rule at Order 100.

SSL Inspection rule structure

Like URL Filtering, SSL Inspection is rule-ordered. Most tenants use this 3-rule pattern:

Order	Name	Action	Match
5	Bypass-Healthcare-Banking	Do Not Inspect	Categories: Banking, Healthcare; Pinned apps
10	Bypass-Executive-Personal	Do Not Inspect	Group: Executives (privacy carve-out)
20	Inspect-All-Else	Inspect	Everything

QUIC and HTTP/3 — the 2025+ blind spot

QUIC encrypts the transport itself (not just the payload), which would render SSL Inspection useless. ZIA's response: block QUIC by default (UDP/443) and force clients to fall back to TCP/443 where ZIA can MITM. If you allow QUIC outbound, you're letting traffic bypass inspection silently. Check this on every tenant.

🔒HSTS Preload — the unbypassable list

HSTS Preload — sites on the HSTS preload list (github.com, paypal.com, many banks) cannot be MITM'd even with a click-through cert warning. If 5% of your fleet doesn't have the Zscaler root cert installed, those sites are hard-broken with no override. Standard outage cause.

File Type Control — the second layer

Even with full SSL Inspection, you might allow a category that lets dangerous files through. "Allow Software Downloads" sounds reasonable until an engineer downloads a cracked .exe from a personal site. File Type Control adds a per-MIME-type filter on top of URL/Cloud App rules.

The classic 4 rules

File category	Default action	Override examples
Executables (.exe, .msi, .dmg, .bat, .ps1, .sh)	Block	Allow for IT group from specific approved sites only
Scripts (.js, .vbs, .ps1, macro-enabled .docm/.xlsm)	Caution + Sandbox	Sandbox before allowing through to the user
Archives (.zip, .rar, .7z, .tar.gz)	Allow + Sandbox if password-protected	Password archives often hide malware — force sandbox
Multimedia / images (.jpg, .mp4)	Allow	Bandwidth cap if abused

MIME validation — don't trust the extension

An attacker renames payload.exe to resume.pdf hoping ZIA matches "PDF allowed" rule. File Type Control checks the actual file magic bytes (MIME signature), not just the extension. A Windows PE binary always starts with MZ bytes — File Type Control catches that regardless of filename. Always enable "Detect File Type by Content" (exact ZIA portal label) in the rule.

File Type Control rule — block executables

Policy → URL & Cloud App Control → File Type Control → + Add Rule

  Order:                10
  Name:                 Block-Executables-Universal
  Action:               Block
  File Types:           Windows Executable (PE), macOS Executable (Mach-O),
                        Linux Executable (ELF), Installer Package (.msi, .pkg, .dmg),
                        Script (.bat, .ps1, .vbs, .sh)
  Traffic Direction:    Upload / Download / Both  (dropdown)
  Detect File Type by Content: Yes  (MIME magic, not extension)
  Group:                All EXCEPT IT-Team
  Notification:         Yes  (user sees "blocked .exe from ")

Then optional Order 5 Allow for IT-Team from approved repos.

💡Pro Tip — pair File Type Control with Sandbox

For "allowed but risky" file types (archives, Office macros, PDFs from new sources), don't just allow — pair the URL/File rule with Zscaler's Cloud Sandbox. The file is detonated in a VM before being delivered. Verdict comes in 1–5 seconds; if clean, user gets the download; if bad, blocked + logged. This catches zero-day malware that signature-based AV misses.

Common SSL Inspection breakages and fixes

⚠Common Mistakes — SSL Inspection

Root CA not pushed before enabling SSL Inspection — every browser breaks at once. Always push the cert first, verify on test endpoints, then flip Inspect ON.
Firefox not configured — Firefox uses its own cert store. Push security.enterprise_roots.enabled=true via Firefox enterprise policy.
Inspecting banking / healthcare — privacy & compliance violation in many jurisdictions. Always Bypass these categories.
Inspecting Microsoft updates — windowsupdate.com uses mutual TLS that breaks under MITM. ZIA's recommended bypass list includes it — keep it on.
Pinned-app failures dismissed as "user issues" — when "Slack won't connect from my laptop" tickets pile up, check pinning. Add to bypass.
Detect-by-content disabled in File Type Control — attacker renames .exe to .pdf, ZIA passes it because extension match was used. Always enable content-based detection.
SSL Inspection rule order wrong — generic "Inspect" rule above the "Bypass pinned apps" rule. All pinned apps break. Bypass rules at the top, always.
HSTS sites and ZIA cert — sites with strict HSTS won't even let the user click-through cert warnings. If Root CA isn't installed, those sites are completely inaccessible. Distribution must precede inspection.

✓Verify — confirm SSL Inspection is working correctly

After enabling SSL Inspection on a test group:

From an inspected endpoint, hit https://github.com → click the lock icon → view certificate. Issuer CN should contain the substring "Zscaler" — exact string varies by Sub-Cloud (zscalerone/two/three/beta/Compliance). Don't string-match the literal "Zscaler Intermediate CA".
Try https://<your-bank>.com from same endpoint. Cert issuer should be the bank's CA (DigiCert / Entrust), NOT Zscaler — proving the bypass rule worked.
ZIA Admin → Insights → Web → filter inspected-traffic-only → confirm URL paths now appear (full path was hidden before inspection).
Hit https://ip.zscaler.com → confirm "Inspected = Yes".

SSL Inspection Troubleshooting Lab Cert Chain Walkthrough

Real-world scenario — Monday morning rollout breaks Slack

You enabled SSL Inspection company-wide over the weekend after distributing the Zscaler Root CA via Intune. Monday morning, the engineering team can't reach Slack desktop. Web browsers work fine — only the Slack native client fails.

Your debug path:

Reproduce on your own laptop: https://slack.com in browser works (Zscaler-issued cert visible). Slack desktop app fails to connect.
Hypothesis: Slack desktop pins its certificate. Confirm by running tcpdump on the loopback during a Slack connect attempt — you see a TLS handshake start, then immediate FIN from Slack process.
ZIA → Insights → Web → filter by destination=slack.com → see the connection attempt logged as "TLS handshake failed — cert verify failed (client rejected)".
Fix: Add Slack to the SSL Inspection bypass rule (Order 5).
Activate. Wait 60s. Test Slack desktop — connects immediately.
Update the runbook: add to the "Pinned Apps — Always Bypass" list. Next time you onboard a tenant, this rule is already in the template.

Total time from ticket to resolution: ~15 minutes once you've seen the pattern. The lesson: every new SSL Inspection rollout should pilot for a week with engineering + sales (highest pinned-app usage) before going to the full company. That week catches 95% of the pinned-app failures with minimal blast radius.

📌 Quick reference (memorise — final lesson of the Forwarding-Auth-Policy arc)

Without SSL Inspection, ZIA sees only SNI — domain only, no URL path, no body, no files.
SSL Inspection = two-legged TLS. Leg A: user ↔ PSE (Zscaler-signed cert). Leg B: PSE ↔ origin (real cert).
Distribute Zscaler Root CA FIRST via Intune/Jamf/GPO/etc. Don't forget Firefox (separate trust store).
SSL Inspection rule order: Bypass rules (banking, pinned apps, executives) at top → Inspect-All at bottom.
Pinned apps to always Bypass: banking, healthcare, Slack desktop, Dropbox, Apple iCloud, Authenticator apps, Microsoft Teams (partial), Windows Update.
File Type Control = MIME-based filter (magic bytes, not extension). Detect-by-content must be ON.
Default file rules: Block executables · Caution + Sandbox scripts/macros · Sandbox password archives · Allow images/multimedia.
Pair File Type Control with Sandbox for risky-but-allowed types.
Verify Inspect: https://github.com cert issuer = "Zscaler Intermediate CA". Verify Bypass: bank URL cert issuer ≠ Zscaler.
Pilot first, broad-rollout second — one engineering+sales week catches pinned-app issues before they hit 4000 users.

▶ QUICK LAB · ~15 MIN

Tune SSL Inspection bypass list:

From a laptop with Zscaler root cert installed, browse to https://www.microsoft.com — verify "Issuer: Zscaler..." in cert chain.
Now browse to https://outlook.office.com — verify it's bypassed (issuer = Microsoft, not Zscaler).
Test a media-plane app: open Webex Meeting → check call quality. If choppy, add *.webex.com to bypass.
Trigger EICAR test: curl https://secure.eicar.org/download/eicar.com — should be blocked by ZIA.

What's next — Lesson 7

Lessons 1–6 covered the foundation, architecture, forwarding, identity, policy, SSL — everything you need to operate ZIA. Next we shift from ZIA into the rest of the security stack: Threat Protection (ATP, Cloud Sandbox, IPS, AV, Browser Isolation, Page Risk Score). The "what catches the actual malicious payload" stack.

Module 7 → ZIA Threat Protection Stack (coming next) Practice ZDTA on exam.techclick.in

SSL Inspection & File Type Control — what ZIA sees inside encrypted traffic