Index › Encrypted Traffic
Revision Guide · Certified Next-Generation Firewall (NGFW) Engineer

Encrypted Traffic

← Back to full guide index

~2 min read
Prerequisites: Foundations, Traffic Classification — decryption is what makes App-ID/Content-ID effective against HTTPS.

SSL/TLS & SSH Decryption 06

NGFWPrisma Access

Learning objectives

  • Explain why decryption is required for App-ID, Content-ID, and Threat Prevention to be effective against HTTPS/SSH traffic
  • Distinguish SSL Forward Proxy, SSL Inbound Inspection, and SSH Proxy by direction of traffic and certificate requirements
  • Identify why HA does not preserve decrypted sessions across a failover

Most traffic today is encrypted, and "you can't block what you don't inspect." Decryption lets the NGFW briefly turn ciphertext back into plaintext, inspect it, then re-encrypt it before it leaves the box.

Why

Attackers hide malware delivery and C2 inside HTTPS; without decryption, App-ID/Content-ID/Threat Prevention are effectively blind to most modern traffic.

How

Three modes: SSL Forward Proxy — for outbound traffic, the firewall acts as a man-in-the-middle proxy, presenting a certificate signed by an internal/enterprise CA trusted by client endpoints. SSL Inbound Inspection — for traffic to your own servers, the firewall holds the server's actual private key so it can decrypt without re-signing. SSH Proxy — decrypts SSH sessions to police tunneling, no certificates needed. All three re-encrypt traffic before forwarding. Decryption is policy-based (decryption policy rules + profiles), so you can exempt categories like finance/healthcare sites for legal reasons.
The three major decryption modes: SSL forward proxy, SSL inbound inspection, and SSH proxy.
The three major decryption modes: SSL forward proxy, SSL inbound inspection, and SSH proxy.

Pros

  • Only way to make Threat Prevention, Advanced URL Filtering, and file inspection actually see HTTPS content
  • Supports Perfect Forward Secrecy (DHE/ECDHE) and HSM-backed private keys
  • Selective decryption by URL category/risk lets you balance privacy vs. inspection

Cons

  • CPU/resource intensive — decrypting everything indiscriminately can be a major performance hit
  • Legal/regulatory limits in some jurisdictions and for some traffic types (banking, healthcare)
  • Certificate trust must be deployed to every endpoint or users get browser warnings
  • HA does not sync decrypted sessions — a failover drops and restarts those sessions under the new node's policy
  • Pinned-certificate apps can break under forward proxy

Exam Trap

Candidates often assume decryption is "set it and forget it." In reality decryption policy is evaluated separately from Security policy (much like NAT), exemptions must be maintained for legally-restricted categories, and — critically — an HA failover does not preserve decrypted session state, so those sessions restart under the new active node's policy rather than continuing transparently.

Self-check: SSL/TLS & SSH Decryption
Q1. A user reports that an internal web app with certificate pinning stopped working after decryption was enabled. What's the likely cause and fix?
A: SSL Forward Proxy substitutes the firewall's own signed certificate for the real one; pinned-cert apps reject that substitute cert and break. Fix by adding a decryption policy exclusion (bypass) for that app/destination.
Q2. You need to inspect traffic destined to an internal server you own, without breaking client trust or re-signing certs. Which decryption mode applies, and why?
A: SSL Inbound Inspection — the firewall holds a copy of the server's actual private key, so it decrypts and re-encrypts using the server's real certificate instead of substituting its own, keeping client trust intact.

Source: pan-os/11-1/pan-os-admin/decryption/decryption-overview

Certificate Management 07

Learning objectives

  • Describe what the forward-trust CA certificate does and why it should chain to an enterprise root CA
  • Explain the operational risk of expired certificates or missing OCSP/CRL checks
  • Identify which firewall functions depend on certificate trust chains (decryption, GlobalProtect, Authentication Portal, admin/API access)

Centralized handling of the keys and certificates that secure decryption, GlobalProtect, the Authentication Portal, and admin/API access, across their full lifecycle.

Why

Decryption, VPN, and admin access all depend on trust chains; an expired or mismanaged certificate silently breaks decryption or locks out VPN users.

How

One admin interface to generate/import certs, add CAs, configure OCSP responders, and set certificate checks. For outbound decryption the firewall auto-generates a copy of the destination's cert, signed by its own forward-trust CA certificate (ideally chained to your enterprise root CA so endpoints trust it silently).
Certificate lifecycle stages and the enterprise root to forward-trust CA chain.
Certificate lifecycle stages and the enterprise root to forward-trust CA chain.

Pros

  • Single pane for cert lifecycle across decryption, VPN, and admin auth
  • Chaining the forward-trust CA to an enterprise root avoids per-endpoint trust errors
  • Supports HSM integration for protecting private keys

Cons

  • Mismanagement (expired certs, missing CRL/OCSP checks) causes major outages, not just warnings
  • Deploying trusted forward-proxy CA certs to every managed and unmanaged endpoint is an ongoing operational burden

Exam Trap

Don't confuse the forward-trust CA certificate (used to sign the firewall's substitute certs during SSL Forward Proxy) with the certificate presented during SSL Inbound Inspection — inbound inspection uses the real server's own key/cert, no forward-trust CA involved. Also remember: if the forward-trust CA isn't chained to (or imported as) a trusted root on client endpoints, every decrypted site throws a browser trust warning even though decryption itself is working correctly.

Self-check: Certificate Management
Q1. Why should the forward-trust CA certificate be chained to your enterprise root CA rather than left as a self-signed cert on the firewall?
A: If it's self-signed, every managed endpoint needs that specific cert manually imported as trusted; chaining it to an enterprise root that's already trusted org-wide (e.g. via AD group policy) lets endpoints trust decrypted sites silently with no per-device import.
Q2. What's the practical impact of an expired certificate used by GlobalProtect versus one used for admin UI access?
A: An expired GlobalProtect certificate can lock out remote VPN users entirely; an expired admin UI certificate typically just throws a browser warning for administrators but doesn't stop production traffic — both are outages of different severity, which is why proactive cert lifecycle tracking matters.

Source: ngfw/administration/certificate-management

Module Quiz

1. An engineer needs to decrypt and inspect inbound traffic to an internally-hosted web server, without the firewall substituting its own certificate to clients. Which decryption mode should be configured?

SSL Inbound Inspection loads a copy of the server's actual certificate and private key onto the firewall, so no certificate substitution or client-side trust changes are needed.

2. A user's outbound HTTPS session to an external site is decrypted via SSL Forward Proxy. What certificate does the client's browser actually see presented?

Forward Proxy is a controlled man-in-the-middle: the firewall generates a substitute certificate on the fly, signed by its own forward-trust CA.

3. After enabling SSL Forward Proxy decryption, a mobile banking app on employee devices begins failing to connect while browser traffic decrypts normally. What is the most likely explanation?

Certificate pinning hardcodes trust to the real server certificate, so any substitute cert — even one legitimately signed by a trusted internal CA — fails validation; the standard remedy is a decryption exclusion for that app/domain.

4. An HA active/passive pair is running SSL Forward Proxy decryption on production traffic. An HA failover event occurs. What happens to sessions that were actively decrypted on the formerly-active node?

Decrypted session state is not synchronized between HA peers, unlike most other session table state, so failover drops those sessions and clients must reconnect.

5. Which of the three primary decryption modes requires no certificates at all to operate?

SSH Proxy decrypts SSH sessions to detect port-forwarding/tunneling abuse using SSH's own key exchange, with no X.509 certificate involved.

6. Which cryptographic capability does the firewall support specifically to preserve forward secrecy on sessions it re-encrypts after decryption?

The firewall supports DHE/ECDHE cipher suites for the re-encrypted leg of the connection, preserving Perfect Forward Secrecy rather than falling back to static RSA key exchange.

7. Why is a forward-trust CA certificate typically chained to an existing enterprise root CA rather than deployed as a standalone self-signed certificate?

Chaining to an already-trusted enterprise root avoids the operational burden of distributing a standalone forward-trust cert to every managed endpoint individually.

8. A firewall's forward-trust CA certificate silently expires without anyone noticing. What is the most likely resulting symptom reported by users?

An expired signing CA means every substitute certificate it has issued is now itself untrusted, which surfaces as browser certificate warnings across every decrypted HTTPS site.
← Traffic ClassificationPolicy & Segmentation →