T Techclick ← Palo Alto hub
Palo Alto · PAN-OS · Decryption · Interactive lesson

PAN-OS SSL/TLS decryption — inspect, then prove it

The ticket says “the banking app is broken,” or “everyone sees a cert warning,” or “SOC cannot see the HTTPS payload.” PAN-OS did not ignore you — you picked the wrong mode, trusted the wrong cert, or never logged the handshake. This lesson is the model, the Policies → Decryption click path, and the log fields that close that ticket.

20 min read · L2 primary · Quiz at end

⚡ Quick Answer

PAN-OS SSL/TLS decryption the way you will use it: Forward Proxy vs Inbound, No-Decrypt vs pinned-app exclusion, Forward Trust, and proof in Traffic + Decryption logs.

After this page you can

Quick answer (say this out loud)

PAN-OS decryption is policy-based. Users leaving the network to the internet match SSL Forward Proxy: the NGFW opens two TLS sessions and presents a Forward Trust impersonation cert (or Forward Untrust if the real issuer is not in its CTL). Traffic arriving at your server matches SSL Inbound Inspection: import that server’s certificate and private key. Traffic you choose not to decrypt (finance, health, executives) is a No Decrypt rule at the top of Policies → Decryption, with a No Decryption profile on TLSv1.2 and earlier. Traffic that cannot be decrypted (pinned certs, client authentication) goes on Device → Certificate Management → SSL Decryption Exclusion. Prove it in Monitor → Logs → Decryption (Policy Name, Proxy Type, TLS version, cipher, Error Index) and Monitor → Logs → Traffic (Decrypted = yes).

1. Why encrypted traffic is still a hole

A Security allow with a profile group does not inspect what it cannot see. Most web sessions are TLS. Without a matching decryption policy, App-ID often stays on ssl, URL Filtering cannot apply HTTPS exceptions cleanly, and Advanced Threat Prevention / WildFire never see the payload.

Official wording is blunt: you cannot block traffic you do not inspect. That is why decryption is its own rulebase — Policies → Decryption — evaluated top-down, first match, separate from Security.

Hero · who talks to whom
User laptop through NGFW Forward Proxy to internet server
Notice: the client is not talking to the real server. The NGFW is a trusted third party with two TLS sessions. If the client does not trust Forward Trust, every site warns.

Three tickets this page is built to close:

Hard words before the runbook

SSL Forward Proxy — outbound MITM. Firewall impersonates the internet server to the client.

SSL Inbound Inspection — inbound MITM. Firewall has your server’s cert + key and inspects clients talking to that server.

Forward Trust / Forward Untrust — the two impersonation CAs. Trust = “server issuer is in our CTL.” Untrust = “we do not trust that issuer; client must warn.”

No Decrypt — policy action you choose (legal / privacy). Still a decryption policy rule so the session is logged.

SSL Decryption Exclusion — hostname list for traffic that breaks if you decrypt (pinning, client auth). Technical, not legal.

2. Mental model · two sessions + two certs

Hold three parts. Interviews fail when people mix them.

1. Two TLS sessions

Client ↔ NGFW and NGFW ↔ server. New session keys on each side. The NGFW decrypts, applies Security + profiles, then re-encrypts. HA does not sync decrypted sessions.

2. The cert the client sees

Forward Proxy: impersonation signed by Forward Trust or Forward Untrust. Inbound: the real server cert (or chain) you imported. If the client already pinned the real leaf, this session dies.

3. Policy, then profile

The decryption rule picks Decrypt / No Decrypt and the Type. The attached decryption profile is the checks (expired cert, weak TLS, unsupported cipher). No profile = you decrypted without hardening.

Say this out loud

Forward Trust on the client is how the user stays silent. Forward Untrust on the client is how you hide a bad issuer. Pinned apps go on the Exclusion list. Finance goes on a No Decrypt rule above the decrypt rule. The Decryption log Policy Name is the evidence — not the Security rule name.

Journey · handshake the firewall actually runs
Four panels: Client Hello, impersonation cert, inspect, re-encrypt
Client Hello hits the NGFW first. The server never sees the client cert store. The client never sees the real leaf unless you are doing Inbound Inspection.

Forward Proxy handshake, official order:

  1. Internal client starts TLS to an external server.
  2. NGFW intercepts the certificate request and acts as the server to the client.
  3. NGFW opens a second session to the real server and looks like the client.
  4. If the server cert is signed by a CA in the NGFW CTL and the profile allows it, the NGFW mints a Forward Trust impersonation cert (SAN copied / CN appended if you enabled that check).
  5. If the issuer is not trusted, the NGFW mints a Forward Untrust copy. The client must warn. That warning is the feature.
  6. Keys are proxied the same way. Cleartext is inspected. Traffic is re-encrypted on the way out.

3. Decision flowchart

Read this before you click Policies → Decryption. The packet does not “find the safest mode.” It walks the decryption rulebase until one rule says Decrypt or No Decrypt.

Path · four exits
Decision diamond splitting traffic into decrypt, inbound, no-decrypt, exclude
Four exits, not two. Legal skip and technical break are different doors. Mixing them is how a pinned app becomes a “finance category” hole.
Flow 1 · pick the door, then the object
Encrypted session arrives · which door? New TLS / SSH session zones + SNI / dest + user Who owns the server cert? We do (inbound) Inbound Inspection import cert + key Internet does Forward Proxy if we will inspect Can / may we decrypt? Legal / privacy No Decrypt rule top of rulebase Pinned / client-auth SSL Exclusion list hostname, technical YES · inspect Decrypt + decryption profile then Security policy + profile group on Allow No Decrypt and Exclusion sit above decrypt-any. First match in Policies → Decryption wins — same as Security. Undecrypted traffic is silent in the Decryption log unless a decryption policy rule owns it.

Read top → down. Diamond = decision. Green is inspect. Amber is a chosen skip. Red is a technical skip. Both skips must exist as objects or the decrypt-any below will still fire.

4. How to choose the mode

Mode is a Type on the Options tab, not a Security action. Mixing Forward Proxy with an imported server key is the classic “inbound never decrypts” ticket.

You needType / actionWhat you attachWhy
Users in trust browsing the internet Decrypt · SSL Forward Proxy Forward Trust + Forward Untrust; SSL Forward Proxy profile NGFW impersonates the destination. Clients must trust Forward Trust only.
Internet clients hitting your published HTTPS server Decrypt · SSL Inbound Inspection Server cert + private key (up to 12 certs per rule); inbound profile NGFW must present the same leaf the server presents. PFS + chain: import the chain.
Finance, health, executives — you choose not to look No Decrypt No Decryption profile (TLSv1.2 and earlier only) Legal / privacy. Place this rule above decrypt. Still logs if the rule exists.
Banking app, dropbox-style pin, client-auth site breaks Leave Decrypt rules alone SSL Decryption Exclusion hostname (or predefined PAN list) Technical. A No Decrypt URL category will not fix a pin on a hostname the category missed.
Mobile apps that pin + TLSv1.3 No Decrypt for those apps, or Max Version = TLSv1.2 on their profile Separate rule + profile TLSv1.3 encrypts certificate data, so automatic exclusion by cert info cannot run.
SSH port-forward tunnels Decrypt · SSH Proxy SSH Proxy profile (no certs) Not on Strata Cloud Manager. Distinguishes ssh vs ssh-tunnel.

Source: Decryption Policy Rules and Define Traffic to Decrypt — “Place rules that exclude traffic from decryption at the top.” Technical breaks go on the SSL decryption exclusion list, not a legal No Decrypt rule.

Do not do this

Do not install the Forward Untrust certificate into any client trust store. Official Configure SSL Forward Proxy: users will stop seeing warnings for issuers the NGFW itself does not trust. Do not attach a No Decryption profile to TLSv1.3 No Decrypt rules — certificate fields are encrypted, so expired-cert / untrusted-issuer checks cannot fire. Still create the No Decrypt rule so the session is logged.

5. Runbook · Side A certs, Side B rule, Side C log

Lab story (placeholder IPs only): users in zone trust (10.1.8.0/24) browse HTTPS to untrust. You will not decrypt financial-services or health-and-medicine. A pinned lab hostname pin.lab.example.com must keep working. Then you prove one decrypted session and one no-decrypt session in logs.

Primary source for clicks: Configure SSL Forward Proxy (PAN-OS & Panorama) and Define Traffic to Decrypt.

Side A — certificates and exclusions first

  1. Confirm the data-plane path can proxy

    Network → Interfaces → Ethernet. Forward Proxy needs Virtual Wire, Layer 2, or Layer 3 — not a tap you only use for Inbound visibility. Proxied Forward Proxy traffic does not carry DSCP / QoS.

  2. Forward Trust (best practice: enterprise CA)

    Device → Certificate Management → Certificates (labeled Device Certificates on PAN-OS 11.2 and earlier) → Generate. Unique Certificate Name per firewall. Common Name = FQDN or IP, no spaces. Signed By = External Authority (CSR) for an enterprise CA, or a self-signed root you mark Trusted Root CA then a subordinate with Certificate Authority checked. After import, open the cert and check Forward Trust Certificate.

    Enterprise-CA path: skip pushing the leaf to endpoints if they already trust that enterprise root. Self-signed path: export PEM without the private key and deploy via GPO / MDM / GlobalProtect Trusted Root CA + Install in Local Root Certificate Store.

  3. Forward Untrust (same cert on every firewall)

    Generate a separate CA. Leave Signed By blank. Check Certificate Authority, then mark Forward Untrust Certificate. Do not export it. Do not install it on clients.

  4. Technical exclusion for the pinned hostname

    Device → Certificate Management → SSL Decryption Exclusion → Add. Hostname pin.lab.example.com. This is the official door for certificate pinning and client authentication. Predefined Palo Alto Networks exclusions already cover many vendor sites — do not delete those rows.

  5. Decryption profiles

    Objects → Decryption Profile → Add. Build three, not one:

    • dp-fwd-strict — SSL Forward Proxy + SSL Protocol Settings. Min Version TLSv1.2 (or TLSv1.3 if you have no pinned mobile apps on this rule). Max Version = Max. Leave DHE + ECDHE on. Block expired certificates, untrusted issuers, unsupported versions and ciphers.
    • dp-no-decrypt — No Decryption tab: Block sessions with expired certificates + Block sessions with untrusted issuers. Attach only to TLSv1.2-and-earlier No Decrypt rules.
    • (If you publish a server later) dp-inbound — SSL Inbound Inspection checks matching what that server actually supports. Separate profile per capability set (RSA-only vs PFS).
https://fw.lab.example.com/#device/certificate-management/certificates Training mock · not live

Device → Certificate Management → Certificates → fw1-fwd-trust

Certificate Information

fw1-fwd-trust
fw1.lab.example.com
corp-root-ca (enterprise)
Forward Trust Certificate · checked
Key = yes · CA = yes
cleared — different cert
Export PEM · no private key OK

Click next: generate lab-fwd-untrust, mark only Forward Untrust, do not export it. Then Objects → Decryption Profile. Source: Device → Certificate Management → Certificates (Configure SSL Forward Proxy, PAN-OS).

Side B — Policies → Decryption

  1. No Decrypt first (position 1)

    Policies → Decryption → Add. Name no-decrypt-finance-health. Source Zone = trust. Destination Zone = untrust. Service/URL Category: URL Category = financial-services, health-and-medicine (predefined). Options: Action = No Decrypt. Decryption Profile = dp-no-decrypt. Log unsuccessful TLS handshakes (default); also check Log Successful TLS Handshakes on the pilot so you can prove the skip.

  2. Forward Proxy second (position 2)

    Name decrypt-users-fwd. Source Zone = trust, Source Address = net-users-trust (10.1.8.0/24). Destination Zone = untrust. Service = any (or application-default if you are excluding apps on default ports only). URL Category = any — the No Decrypt rule above already carved finance/health. Options: Action = Decrypt, Type = SSL Forward Proxy, Decryption Profile = dp-fwd-strict. Enable Log Successful TLS Handshakes on the pilot.

  3. Optional inbound later

    A third rule, Type = SSL Inbound Inspection, Destination Address = the published server, Certificates = the imported server leaf (and the next leaf before cutover — up to 12). Do not put Forward Trust here. The NGFW checks that the Server Hello cert matches a cert on the rule; mismatch ends the session and the Decryption log says so.

  4. Block QUIC so browsers fall back to TLS

    This is a Policies → Security pair, not a decryption rule. Block application quic, and block UDP services 80 and 443. Official best practice: Chrome will otherwise stay on proprietary encryption the NGFW cannot decrypt.

  5. Commit

    Decryption policy is not live until Commit. Generate one subordinate Forward Trust per firewall so a revoke does not take down the fleet.

https://fw.lab.example.com/#policies/decryption Training mock · not live

Policies → Decryption → Add

Decryption Policy Rule

General Source Destination Service/URL Category Options
decrypt-users-fwd
2 · below no-decrypt-finance-health
trust · net-users-trust
untrust
Decrypt
SSL Forward Proxy
dp-fwd-strict
Successful + unsuccessful TLS handshakes
Cancel OK · then Commit

Click next: OK, Commit, browse HTTPS from 10.1.8.41, then open Monitor → Logs → Decryption. Source: Policies → Decryption (Define Traffic to Decrypt, PAN-OS).

Side C — prove it in Traffic + Decryption logs

  1. Generate two sessions

    From 10.1.8.41: fetch a normal HTTPS site (should decrypt) and a financial-category site (should no-decrypt). Leave the pinned hostname for a third pass if you have it.

  2. Traffic log — Decrypted flag

    Monitor → Logs → Traffic. Filter (addr.src in 10.1.8.41). On the decrypted session: Application should move off bare ssl once identified, Action = allow, and the Decrypted column = yes. On the finance session: Decrypted = no, and the Security rule still allowed it.

  3. Decryption log — the close

    Monitor → Logs → Decryption. This log exists only for sessions a decryption policy rule owns (including No Decrypt). Quote Policy Name, Proxy Type (forward / no-decrypt / inbound), TLS Version, cipher / key-exchange, SNI, Root Status, and on failures the Error / Error Index.

https://fw.lab.example.com/#monitor/logs/decryption Training mock · not live

Monitor → Logs → Decryption

Decryption · filter (addr.src in 10.1.8.41)

13:12:04 sni=news.example.com policy=decrypt-users-fwd proxy=forward tls=TLS1.3 decrypted=yes root=trusted
13:12:11 sni=bank.example.com policy=no-decrypt-finance-health proxy=no-decrypt tls=TLS1.2 decrypted=no root=uninspected
13:11:58 sni=pin.lab.example.com policy=decrypt-users-fwd error=received fatal alert · add hostname to SSL Decryption Exclusion
Export CSV Add to filter · policy_name eq decrypt-users-fwd

Green close: Policy Name is yours, Proxy Type matches the Options tab, TLS version is what you intended, Error Index is empty on the happy path. Source: Configure Decryption Logging + Decryption Log Errors.

Green success = these fields

Monitor → Logs → Decryption: policy_name=decrypt-users-fwd · proxy_type=forward · TLS 1.2 or 1.3 · no Error Index. Same source in Traffic: Decrypted=yes, Application is a real App-ID at session end, Action = allow. Finance session: policy_name=no-decrypt-finance-health, Decrypted=no. Pinned hostname: either Exclusion cache / list, or a handshake error you then exclude — not a second decrypt rule.

Ops · proof cockpit
Operations desk verifying decryption log health
Commit is not proof. A Decryption log row with your Policy Name is proof. Default logging is unsuccessful handshakes only — turn on successful for the pilot.
CLI filters you will actually type
show session all filter source 10.1.8.41 destination-port 443
show log decryption direction equal backward receive_time in last-hour
show log traffic direction equal backward ( addr.src in 10.1.8.41 ) and ( decrypted eq yes )

6. Runtime path after commit

After go-live the firewall does not re-read your intent. It does this.

Flow 2 · session after commit
One TLS session · exclude, match, proxy, inspect, log 1 · Ingress zone + Client Hello SNI if visible 2 · Exclusion list predefined + custom hostname / pin 3 · Decrypt rule top-down first match Decrypt / No Decrypt 4 · Two sessions + profile Trust or Untrust impersonation or imported inbound leaf 5 · Cleartext → Security + profiles App-ID / URL / Threat / WildFire then re-encrypt toward dest or skip inspect No Decrypt / Exclusion / QUIC Security still matches — payload dark Logs write only if a decryption policy rule owns the session Default = unsuccessful handshakes. Pilot = also log successful. Root Status = uninspected on no-decrypt and many TLS1.3 skips. URL Filtering reset during handshake never appears in Decryption logs — look in URL Filtering logs instead. HA failover: decrypted sessions are not synced. New sessions decrypt again after the fail-over.

Security policy still runs on undecrypted traffic. You get an allow/deny, not a payload. That is why “the Security rule hit” is not proof of inspection.

7. Traps + proof checklist

TrapWhat you seeWhat is true
Forward Trust never landed on the client Every HTTPS site warns after commit Self-signed path needs GPO/MDM/GlobalProtect. Enterprise-CA path needs the subordinate marked Forward Trust, not the root.
Forward Untrust in the trust store No warnings on junk issuers You taught the browser to trust what the NGFW itself does not trust. Remove it.
No Decrypt below decrypt-any Finance is still decrypted Decryption rules are first match. Move the skip to the top.
Pinned app treated as a URL category skip App still dies; category never matched Use Device → Certificate Management → SSL Decryption Exclusion (hostname). Technical ≠ legal.
No Decryption profile on TLSv1.3 Expired / untrusted issuer still allowed Certificate fields are encrypted. Profile checks cannot run. Keep the No Decrypt rule for logging.
Inbound without the private key Session end = firewall/server certificate mismatch Import cert + key (and chain for TLS1.2 + intermediates). Add the next cert before you swap the server leaf.
QUIC allowed Chrome works, Decrypted = no, App-ID stays empty-ish Block quic and UDP/80+443 so the browser falls back to TLS.
Only unsuccessful handshakes logged Happy path is invisible Options → Log Successful TLS Handshakes on the pilot. Watch Device → Setup → Management → Logging and Reporting Settings quota (default decryption log is 1%).
Client authentication / pin + proxy Fatal alert, Local SSL Decryption Exclusion Cache grows NGFW is a proxy — it cannot do true mutual TLS. Exclude the hostname or block client-auth in the profile if the app is not required.
Pilot checklist before you call it done

Knowledge check

Six judgment items. Same facts as the runbook. Check answers, then reset if you mixed No Decrypt with the Exclusion list or put Untrust in a trust store.

Q1

Users in zone trust browse HTTPS on the internet. You want Threat and URL inspection of that payload. Which Options tab do you set on Policies → Decryption?

Correct: a. Outbound users to the internet is SSL Forward Proxy. Inbound Inspection is for traffic to your server using that server’s cert + key. Security profiles cannot inspect ciphertext. Re-read How to choose + mental model.
Q2

A junior engineer exports the Forward Untrust CA and GPO-installs it into every laptop’s Trusted Root store “so users stop complaining.” What did they just break?

Correct: c. Official Configure SSL Forward Proxy: do not install Forward Untrust on clients. The warning is how users see that the real issuer is untrusted. Re-read Side A + traps.
Q3

A corporate banking app dies the minute you commit decrypt-users-fwd. The vendor documents certificate pinning. Finance URL category does not match the API hostname. First fix?

Correct: b. Pinning is a technical break. Official door is the SSL Decryption Exclusion list, not a legal No Decrypt category and not “make the impersonation equal the pin.” Re-read decision flow + Side A step 4.
Q4

You created no-decrypt-finance-health and attached dp-no-decrypt (block expired + untrusted issuer). Traffic is TLSv1.3. Users still reach a bank with an expired chain. Why did the profile not save you?

Correct: d. Official Decryption Profiles: do not attach a No Decryption profile to TLSv1.3 traffic you skip — the checks have no certificate data. Still keep the No Decrypt rule so the session is logged. Re-read How to choose + traps.
Q5

How do you prove decrypt-users-fwd actually inspected 10.1.8.41 → news.example.com?

Correct: b. Decryption log Policy Name is the decryption rule that won. Traffic Decrypted = yes is the session flag. A Security hit only proves allow/deny. Re-read Side C + green success.
Q6

decrypt-users-fwd (Decrypt, any URL) sits at position 1. no-decrypt-finance-health sits at position 4. After commit, bank.example.com is still decrypted. First fix?

Correct: a. Official Define Traffic to Decrypt: exclude rules at the top; decryption policy is evaluated top to bottom. Logging does not change match. Re-read decision flow + Side B.

Sources

Related: PAN-OS Security policy · PAN-OS session factory · Traffic not passing · Logging and reporting · Palo Alto interview hub · Palo Alto course