TTechclick All lessons
Palo Alto · NGFW Decryption · SSL/TLSInteractive · L2 / L3

Palo Alto SSL Decryption — Forward Proxy, Inbound, No-Decrypt in 12 Minutes

~90% of internet traffic is encrypted. If you don't decrypt, half your threat profiles are blind. Pick a decryption mode below, watch the TLS handshake actually transform live, build a No-Decrypt rule in the in-page widget — and you're done.

📅 2026-05-25 · ⏱ 12 min · 3 interactive demos · 🏷 10-Q assessment + AI Tutor inline

Pick a decryption mode — jump straight to it

1

SSL Forward Proxy

Inspect your users going out to the internet. The 80% case for corporate decryption.

 2

SSL Inbound Inspection

Protect your published web servers from encrypted exploit traffic.

 3

No-Decrypt list

Bank, hospital, government, pinned mobile apps — must NOT be decrypted.

 4

TLS 1.3 + Troubleshoot

App broke after decryption? 5-step playbook + pinned-cert diagnosis.

Why decryption exists — the one number that ends the debate

Google's transparency report puts encrypted web traffic at ~95%. If your firewall can only inspect cleartext, you're inspecting roughly the 5% that nobody hides malware in. Every Anti-Virus, Anti-Spyware, URL Filtering, File Blocking and WildFire signature is matched against the payload — and the payload is only visible after the firewall decrypts it.

One sentence to memorise: "Decrypt the unknown, never the regulated." Outbound traffic to unknown sites? Decrypt. Banking, healthcare, government sites? Always No-Decrypt — for legal reasons, not technical ones.

🔐
Why decrypt at all
tap to flip

Threat profiles (AV, AS, Vuln, WildFire) only see cleartext. No decrypt = no inspection = malware passes inside an HTTPS tunnel undetected.

🛡
Forward Proxy
tap

Firewall acts as a man-in-the-middle for users going out. Re-signs the server's cert with your internal CA. Client sees firewall's cert (trusted via GPO).

📥
Inbound Inspection
tap

Firewall holds the server's real private key. No re-signing. Decrypts inbound flows to your published server so threat profiles can scan exploit traffic.

🚫
No-Decrypt
tap

Skip decryption — for regulated content (financial, health) or pinned mobile apps. Still attaches a no-decryption profile to validate the server cert without breaking the session.

① SSL Forward Proxy — the 80% case

Sneha at Infosys opens https://news.example.com. She expects a clean TLS session to the server. The firewall has a different plan — it intercepts the handshake, presents its own certificate to her browser, and runs a separate TLS session to the real server. Two half-sessions, one logical flow, fully inspectable in the middle.

▶ Watch the Forward-Proxy handshake transform

Click Play. Each stage lights up as the firewall splits the TLS session.

① CLIENT HELLO Sneha's browser → firewall · TLS Client Hello, SNI = news.example.com
SNI is what the firewall uses to look up the URL category — happens BEFORE decryption.
▼
② DECRYPT MATCH URL category = news → not in No-Decrypt list → Decryption Profile applies, mode = SSL Forward Proxy.
▼
③ FW ↔ SERVER Firewall opens its OWN TLS session to news.example.com — fetches the real server cert, validates it (OCSP / CRL / cert chain).
▼
④ FAKE CERT Firewall generates a new cert for news.example.com, signed by the Forward Trust CA — installed in Sneha's browser via GPO.
▼
⑤ CLIENT TLS UP Sneha's browser sees Issuer: Infosys-Internal-CA. Trust chain succeeds (CA in cert store). Handshake completes.
▼
⑥ INSPECT Two TLS sessions, plaintext in the middle. Threat profiles (AV / AS / Vuln / WildFire / URL / File / DNS) all see the payload now.
Press Play. Notice stage 4 — the cert Sneha's browser sees is NOT the real one. It's a freshly minted cert from the firewall's internal CA.

The two certificates that make Forward Proxy work

✅
Forward Trust
tap

Used when the real server cert is valid. Firewall signs the fake cert with this CA. Pushed to every corporate endpoint via GPO so browsers don't show warnings.

⛔
Forward Untrust
tap

Used when the real server cert is broken (expired, self-signed, wrong CN). Firewall signs the fake cert with THIS CA — which is NOT in the trust store. Browser shows a warning. User sees the truth.

🔑
Why two CAs
tap

So the firewall can tell the user when the upstream cert is bad. If it always used Forward Trust, even broken server certs would look fine to the user — a silent security regression.

🏷
Pushing the trust CA
tap

The Forward Trust CA must be in every device's Trusted Root store. Done via GPO on Windows, MDM on macOS / iOS / Android. Forget BYOD? You get a flood of cert warnings.

Quick check · Q1 of 10

Sneha at Infosys configures SSL Forward Proxy. Browsers on corporate laptops show no certificate warnings, but personal phones (BYOD) on the Wi-Fi all get warnings on every site. What's the most likely cause?

Correct: c. Forward Proxy works because the firewall's Forward Trust CA is trusted by the client's cert store. Corporate laptops get the CA via GPO. BYOD doesn't. Two clean fixes: (1) put BYOD on a separate Wi-Fi SSID that bypasses decryption, or (2) require MDM enrollment that pushes the CA. Option (1) is what most enterprises pick.

② SSL Inbound Inspection — protect your published server

Rahul at TCS publishes https://portal.tcs.com on a public IP. Internet users hit the firewall, firewall decrypts using a copy of the server's real private key, inspects the cleartext for exploit attempts, then re-encrypts to the backend. No fake cert, no warnings — because the firewall is using the real server's key, not generating new ones.

▶ Inbound Inspection — no re-signing

External user → company's public web app. Firewall holds the server's private key.

① INTERNET USER Client opens TLS to portal.tcs.com (public IP, behind firewall).
▼
② SERVER HELLO Firewall responds as the server — using the REAL server cert + matching private key (loaded onto the firewall).
⚠ Private key MUST be installed on the firewall. No copy = no decryption.
▼
③ NO NEW CERT The client sees the REAL cert — no warnings, no re-signing. Firewall just has the key to decrypt symmetrically.
▼
④ INSPECT Plaintext visible to firewall. Vulnerability Protection profile scans for exploits hitting portal.tcs.com — SQLi, XSS, RCE attempts.
▼
⑤ FW → SERVER Firewall opens a new encrypted leg to the real backend server using the same negotiated cipher.
▼
⑥ RESPONSE Server responds; firewall decrypts again on the reverse direction. Two TLS legs again — but using the SAME cert.
Notice the difference from Forward Proxy — the firewall doesn't generate a new cert here. It's using the server's actual private key.
Inbound Inspection — three killer constraints

1. Doesn't work with (EC)DHE key exchange on PAN-OS < 10.0 (forward-secrecy ciphers don't expose the session key to anyone who only has the RSA private key). PAN-OS 10.0+ supports ephemeral key exchange via a key-exchange proxy on the dataplane. 2. No HA-sync of decrypted sessions — failover means re-handshake. 3. Doesn't work with client-cert authentication (mutual TLS).

Quick check · Q2 of 10

Priya at HCL is setting up SSL Inbound Inspection for https://crm.hcl.com. Which file MUST she load onto the PAN-OS device — and which file should she NEVER load anywhere except this firewall?

Correct: a. Inbound Inspection requires the server's actual private key (plus cert chain). The firewall uses the key to decrypt incoming sessions. Treat the key like a crown jewel — anyone with it can impersonate your server. Don't email, don't store in Git, don't copy to dev firewalls. Use Panorama's secure secret distribution or load directly via SCP / GUI on the production firewall only.

③ No-Decrypt — the legal half of decryption

Karthik at Flipkart hits https://hdfcbank.com on the corporate Wi-Fi. The firewall sees the SNI, looks up the URL category — financial-services. The No-Decrypt rule fires before the Forward Proxy rule could, the session passes through encrypted. Why? Two reasons: legal exposure (storing decrypted banking session data is a regulator's nightmare) and breakage (banks frequently pin certs).

▶ Decrypt-or-Bypass decision tree

Pick a destination — watch how the firewall decides decrypt vs No-Decrypt.

① SNI INSPECT Firewall reads the Client Hello → extracts SNI (server name) + URL category lookup against the PAN-DB cloud.
▼
② RULE TOP Decryption rule #1: No-Decrypt for financial-services, health-and-medicine, government. Evaluated FIRST.
▼
③ MATCH? Site categorised as financial-services? → YES → action = No Decrypt → session passes through encrypted.
No-decryption profile still validates the server cert chain — broken cert is still blocked.
▼
④ ELSE — RULE 2 If not matched: try Decryption rule #2 — Forward Proxy for all other. The decryption profile applies the broad inspection.
▼
⑤ PRE-DECRYPT PROFILE Profile checks: unsupported cipher? Expired cert? Self-signed? Untrusted issuer? → block before decrypt.
▼
⑥ DECRYPT & INSPECT Plaintext available. AV / AS / Vuln / URL / WildFire / DNS all see payload. Re-encrypt + forward.
Press Play to step through the decision. The No-Decrypt rule must be evaluated BEFORE the Forward-Proxy rule — order matters.

The four categories most enterprises No-Decrypt by default

🏦
financial-services
tap

Banks, payment portals, stock trading. Storing decrypted PAN/CVV/account data triggers PCI-DSS, RBI, and SEBI exposure. Universal No-Decrypt.

🏥
health-and-medicine
tap

HIPAA / DPDP Act (India 2023) treat health records as sensitive personal data. Decrypting = liable for any leak. Always bypass.

🏛
government
tap

gov.in, IRS, tax portals. Often pinned certs; decrypting either breaks the site or invites a regulator's audit. Bypass.

📱
PAN-OS predefined
tap

Palo Alto ships a curated list of known-pinned-cert apps in content updates (Zoom, Teams, banking apps, MS Updates). Refreshed weekly.

Quick check · Q3 of 10

Aditya at Wipro enables decryption for the whole company. Two days later, mobile-banking apps stop working on corporate Wi-Fi. Errors say "certificate not trusted". What's the precise fix?

Correct: d. Pinned apps bake the bank's cert (or its public key) into the app binary. They don't honour the local trust store, so the firewall-signed cert fails. You can't fix it inside the app — you have to bypass decryption for those flows. Add the financial-services No-Decrypt rule at the TOP of the rulebase. Enable Palo Alto's Predefined Decryption Exclusions in Decryption Profile → SSL Decryption → SSL Protocol Settings. Both are needed.

④ TLS 1.3, pinning, and the "site broke after decryption" playbook

TLS 1.3 hides parts of the handshake (the certificate exchange) inside the encrypted portion of the conversation. The firewall can still decrypt TLS 1.3, but a couple of TLS-1.2-era tricks no longer work — including auto-bypass based on cert info, because that cert info now arrives encrypted. Cert-pinning apps add their own ceiling.

▶ 5-Step "decryption broke my site" diagnosis

User reports a site / app stopped working after decryption rollout. Run this ladder in order.

① CHECK DECRYPTION LOG Monitor → Logs → Decryption. Look for the destination → error code. decryption-fail-unsupported-mode? untrusted-issuer? Code tells you 80% of the story.
▼
② SNI vs URL CATEGORY test url <domain>. If the category is wrong (PAN-DB miscategorised the site as news instead of health-and-medicine), your No-Decrypt rule never fires.
▼
③ IS IT PINNED? Check Palo Alto's predefined exclusions list. Try the app from a phone OFF the corporate Wi-Fi — works = it's a pinning issue.
▼
④ TLS 1.3 ONLY? Check the cipher in the decryption log. If the site only does TLS 1.3 with ECH (Encrypted Client Hello), even the SNI is hidden — firewall can't categorise correctly. Add the FQDN to a custom No-Decrypt rule.
▼
⑤ ADD TO No-Decrypt Confirmed pinned / TLS-1.3-broken? Create a custom URL category with the specific FQDN → No-Decrypt rule at the top of the rulebase.
▼
⑥ COMMIT & TEST Commit. Verify via show session id <N> — decrypted field should now show False.
Most "site broke" reports resolve in steps 1-3. Steps 4-5 catch the modern TLS 1.3 / ECH edge cases.
CLI — confirm if a session was actually decrypted 
show session id 12345 | match decrypted
Expected output (decrypted session) 
decrypted: True
ssl-decrypt-mirror-port:
TLS 1.3 best practice — the two-rule pattern

Rule A (top): Decryption rule for mobile-app categories with Max-Version = TLS 1.2 in the profile. Forces those apps to TLS 1.2 (where the firewall can still see cert info pre-decrypt to auto-bypass pinned ones). Rule B (below): Generic decryption rule with TLS 1.3 enabled for the rest of the traffic. Per Palo Alto's TLS 1.3 best-practice doc, this split lets you keep modern TLS for browsers while preserving the auto-bypass safety net for mobile apps.

Quick check · Q4 of 10

Sneha enables TLS 1.3 in the decryption profile. Suddenly several mobile-only apps that worked yesterday stop working today. Which is the cleanest fix per Palo Alto's published best practice?

Correct: b. TLS 1.3 encrypts the certificate info — the firewall can't see cert pinning markers pre-decrypt to auto-bypass. Capping mobile-app categories at TLS 1.2 keeps that auto-bypass working for the apps most likely to break. The rest of the traffic still benefits from TLS 1.3. This is Palo Alto's published TLS 1.3 best practice.

🤖 Ask the AI Tutor

Tap any question — instant context-aware answer. No login, no waiting.

Pre-curated answers from PAN-OS docs + LIVECommunity. For complex prod issues, paste your decryption log + show session id output into chat.techclick.in.

📝 Wrap-up — six more

You've already answered 4 inline. Six left. 70% (7 of 10) total marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Apply

In which decryption mode does the firewall present a freshly-generated certificate (signed by an internal CA) to the client — and require that CA in the client's trust store?

Correct: a — Forward Proxy. Forward Proxy is the only mode where the firewall acts as an MITM and signs a brand-new cert with the Forward Trust CA. Inbound Inspection uses the SERVER's real cert + key (no re-signing). Decryption Mirror just clones decrypted traffic to a packet capture appliance. No Decrypt skips the whole thing.
Q6 · Analyze

PAN-OS evaluates decryption policy and security policy as separate rulebases. Where does the firewall identify the URL category — before or after the SSL decrypt — and why does that matter?

Correct: c. SNI is in cleartext (in TLS 1.2 and most TLS 1.3 deployments without ECH). The firewall extracts it from the Client Hello, queries PAN-DB for the URL category, then evaluates decryption rules. This pre-decrypt categorisation is exactly what lets you say "skip decryption for financial sites" without having to actually decrypt them first. With TLS 1.3 + ECH the SNI is encrypted — that's the edge case discussed in section ④.
Q7 · Analyze

Decryption policy rules are evaluated top-to-bottom, first match wins. Where in the rulebase should a No-Decrypt rule for financial-services live?

Correct: b. Per Palo Alto's published best practice, rules that exclude traffic from decryption belong at the TOP of the rulebase. Decryption is top-down, first-match-wins, so a No-Decrypt for financial-services has to fire before any broad "decrypt-all-other" rule. Get this wrong and bank traffic gets decrypted (regulator nightmare).
Q8 · Analyze

An auditor asks: "Show me proof that no banking traffic has been decrypted in the last 30 days." Which combination of PAN-OS artefacts gives the cleanest evidence?

Correct: d. PAN-OS 10.x+ added a dedicated Decryption log (Monitor → Logs → Decryption). It shows the exact action per session — decrypt / no-decrypt / decryption-fail. Filter by URL category + action = no-decrypt. Cross-reference Traffic logs to confirm no flows in those categories carry decrypted=yes. Save as a scheduled report — auditor gets monthly evidence automatically.
Q9 · Evaluate

A SOC team wants to send a copy of decrypted traffic to a NetWitness or Solera packet-capture appliance for archival. Which feature do they need — and which non-obvious legal step is required first?

Correct: c. Decryption Port Mirroring (also called decryption mirror) clones decrypted traffic onto a dedicated mirror interface for downstream tools. It needs a separate license. Palo Alto's docs explicitly say to consult corporate counsel before enabling — decrypted SSL traffic is regulated in many jurisdictions (think GDPR, India's DPDP). Decryption Broker is different — it forwards decrypted traffic to a chain of security tools for in-line inspection.
Q10 · Evaluate

A team is about to roll out SSL decryption to 5,000 users across 12 sites. What sequence of steps minimises user-impact and audit risk?

Correct: b. Palo Alto's deployment best-practice sequence (paraphrased): App-ID first, so port-based holes don't surprise you mid-rollout. CA distribution next — without it, every TLS site shows warnings. No-Decrypt rules + predefined exclusions BEFORE the broad Forward-Proxy rule. Pilot, monitor, expand. Skipping any step turns into a help-desk avalanche on day 1.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the section that tripped you up and tap "Try again".

📚 Sources

  1. Palo Alto Docs — SSL Forward Proxy & SSL Inbound Inspection (PAN-OS 11.x). docs.paloaltonetworks.com
  2. Palo Alto Docs — Decryption Profiles & Decryption Overview. docs.paloaltonetworks.com
  3. Palo Alto Docs — TLSv1.3 SSL Decryption Support (PAN-OS 10.1/11.0). docs.paloaltonetworks.com
  4. Palo Alto Docs — Predefined Decryption Exclusions & Troubleshoot Pinned Certificates. docs.paloaltonetworks.com
  5. Palo Alto Best Practices — Deploy SSL Decryption Using Best Practices. docs.paloaltonetworks.com
  6. LIVECommunity — Usage Difference between SSL Forward Proxy and Inbound Inspection (thread 284409); TLS 1.3 is Coming (thread 232981). live.paloaltonetworks.com
  7. Palo Alto Docs — Configure Decryption Port Mirroring & Decryption Mirroring. docs.paloaltonetworks.com

What's next?

Decryption depends entirely on certificates — Forward Trust, Forward Untrust, the server cert for Inbound Inspection. Next blog opens up the certificate & PKI side of PAN-OS: which cert object belongs where, OCSP / CRL, certificate renewals without outage.

Blog 9 · Certificates & PKI → ← Recap NAT Deep-Dive