Encrypted Traffic

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

There are three modes, and which one applies depends entirely on whose traffic you're decrypting and in which direction — mixing them up is the single most common source of confusion here:

• SSL Forward Proxy — internal users going out to the internet, where you don't own the far end. The firewall becomes what's literally called a "meddler in the middle": it splits one connection into two separate TLS sessions — client-to-firewall, and firewall-to-server — and each side believes it's talking directly to the other. Step by step: the client tries to start a TLS session with the real server; the firewall intercepts that and, to the client, is the server; the firewall separately opens its own session to the real server, which sees the firewall and believes it's the real client; the real server sends back its actual certificate; the firewall checks whether that certificate is signed by a CA it trusts. If it is, the firewall generates a copy of that certificate — an SSL Forward Trust impersonation cert — signed by its own internal CA, and hands that copy to the client. If the real server's cert isn't trusted, the firewall instead issues an SSL Forward Untrust copy, which makes the client's browser show a warning — which is actually the point: it means the firewall correctly detected an untrusted destination and is telling the user, rather than silently passing bad traffic through. For the client to trust the Forward Trust copy without a browser warning every time, its issuing CA has to already be trusted by the client — which is exactly why that CA should chain to your enterprise root (covered in the next section) rather than being a random self-signed cert nobody's endpoint trusts.
• SSL Inbound Inspection — outside traffic coming in to a server you own. Here the firewall doesn't need to impersonate anything, because it isn't trying to fool either side — it holds an actual copy of your server's real private key, so it can decrypt the session using the server's genuine certificate and re-encrypt it the same way, completely transparent to the connecting client. No substitute certificate, no impersonation, no trust warning possible — the tradeoff is that this only works for traffic to servers where you legitimately control (and can hand over) the private key.
• SSH Proxy — for SSH sessions specifically. This decrypts SSH traffic to check what's actually being tunneled inside it (SSH is commonly abused to smuggle other traffic through an otherwise-allowed session) — and unlike the SSL modes, there's no certificate involved at all, because SSH's own key exchange mechanism is what's being intercepted, not a PKI trust chain.

All three modes re-encrypt the traffic before it leaves the firewall — decryption is never a permanent, in-the-clear pass-through, only a brief window for inspection. And crucially, decryption itself runs off its own separate policy layer — decryption policy rules and decryption profiles — evaluated independently of Security Policy, much like NAT is its own layer. That separation is what makes it practical to exempt specific categories (banking, healthcare) from decryption for legal/regulatory reasons without touching your actual security rulebase at all.

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

Certificate Management is one admin interface covering the full lifecycle a certificate goes through: generate or import certificates, add trusted CAs, configure OCSP responders (services that answer "has this certificate been revoked?" in real time), and set which certificate checks are enforced. It's centralized because the alternative — juggling certificate expiry and trust separately for decryption, GlobalProtect, Authentication Portal, and admin/API access — is exactly how a certificate silently expires unnoticed until something breaks in production.

The forward-trust CA, specifically — why it exists and why the chain matters. Recall from SSL Forward Proxy: when the firewall decrypts outbound traffic to a trusted destination, it doesn't hand the client the real server certificate — it generates its own impersonation copy and signs that copy with a CA certificate it holds, called the forward-trust CA certificate. The client's browser only trusts that generated copy if it already trusts the CA that signed it. Two ways to get there: import that specific CA cert as trusted on every single endpoint manually (a real operational burden that scales badly), or — the better path — have the forward-trust CA itself chained to your enterprise root CA, the same root that's presumably already pushed out and trusted fleet-wide via something like AD group policy. Chain it correctly, and every managed endpoint trusts decrypted sites silently with zero extra per-device work; leave it self-signed and unchained, and users see a certificate warning on every single decrypted site, even though decryption itself is functioning correctly — a very common source of "is decryption broken?" tickets that are actually just a trust-chain gap.

Why

The firewall needs two structurally different certificate questions answered: "when someone presents a certificate to authenticate to me, how do I decide whether to trust it" (an incoming-trust question) versus "when I present myself as a TLS endpoint to someone else, which identity and TLS version do I offer" (an outgoing-identity question). Conflating these is a common real-world misconfiguration, which is exactly why the exam blueprint calls out certificate profiles and SSL/TLS service profiles as separate named items.

How

Certificate Profile — validates certificates presented TO the firewall. A Certificate Profile defines user and device authentication settings referenced by Authentication Portal, multi-factor authentication, GlobalProtect, site-to-site IPSec VPN, external dynamic list validation, dynamic DNS, User-ID/TS agent access, and admin web interface access. Configuring one means: assigning one or more trusted CA certificates (the chain the presented cert must validate against), and defining revocation checking — CRL, OCSP, or both (if both are enabled, OCSP is tried first and CRL is the fallback only if the OCSP responder is unreachable). You then choose the specific blocking behavior: block if status comes back unknown, block if status can't be retrieved within a timeout, block expired certificates, and — GlobalProtect-specific — block if the certificate's serial number doesn't match the endpoint's reported host ID. Each of these is an independent checkbox, meaning a profile can be configured to fail open on some conditions and fail closed on others, which is a deliberate design choice admins have to make explicitly rather than getting a single "strict/lenient" toggle.

SSL/TLS Service Profile — controls what the firewall presents to inbound connections. Where the Certificate Profile is about validating someone else's certificate, an SSL/TLS Service Profile defines the server certificate, minimum/maximum TLS protocol version, and cipher settings a firewall service presents outward — referenced by the management interface, GlobalProtect portals and gateways, the Authentication Portal, the "URL Admin Override" password-protected HTTPS page, and the User-ID syslog listening service. Configuring one means setting a Name; a Location (vsys or Shared, on multi-vsys firewalls); a Certificate (must be a signed certificate — a CA certificate cannot be selected here); and Min Version / Max Version (TLSv1.0/1.1/1.2/1.3). Palo Alto's own documented recommendation is TLSv1.3 for both Min and Max on profiles serving Administrative Access, GlobalProtect, and Authentication Portal, and TLSv1.2 for both Min and Max on profiles serving every other referencing service — because TLSv1.3 support is restricted specifically to those three service types; other services referencing an SSL/TLS Service Profile don't support it. An optional Key Exchange Algorithm setting controls RSA/DHE/ECDHE (all enabled by default), and PAN-OS 12.1.2+ adds post-quantum ML-KEM key exchange (security levels 1, 3, or 5) for TLSv1.3 only — though a post-quantum certificate itself still cannot be selected as the profile's certificate. If an incoming connection's protocol version falls outside the profile's configured Min/Max range, the firewall automatically negotiates down or up to the nearest version it does support, rather than simply dropping the connection — a detail worth remembering since "outside the range" doesn't automatically mean "connection refused."

The Decryption Profile is a third, separate object — the most common source of confusion. Neither of the above two objects control SSL Forward Proxy or SSL Inbound Inspection decryption policy behavior (minimum TLS version to allow, which cipher suites are permitted, certificate validation failure handling for decrypted sessions) — that's the job of a Decryption Profile, attached to a Decryption policy rule, and it's a distinct configuration object from both the Certificate Profile and the SSL/TLS Service Profile even though all three deal with "certificates and TLS." An exam question naming a decryption-specific TLS setting and asking which profile controls it is testing exactly this three-way distinction.