SSL Forward Proxy Broken in Three Directions

Why it fails: the category is unknown, which means the URL database could not classify the flow (IP-literal endpoint, CDN hostname with no useful SNI, or a lookup miss). A decryption policy built on URL categories cannot match what it cannot categorise, so the no-decrypt exemptions never apply to those endpoints, and anything that pins or strictly validates certificates breaks. Separately, confirm the forward trust CA is actually in the machine trust store - a CAUTHORITY_INVALID error is also exactly what an untrusted root produces, and the two causes look identical to the user.

Durable fix (in order of preference):

1. Exempt by App-ID: a no-decrypt rule matching the SaaS application, placed above the decrypt rule, so the exemption follows the app rather than a URL category.
2. Exempt by a destination EDL fed from the vendor's published ranges - resilient to CDN shuffling, with a named owner for refreshes.
3. Only as a last resort, add the vendor to the SSL Decryption Exclusion list: it is per-application, needs App-ID to work, and is easy to forget.

Proof: filter the decryption log by user and reason fields, confirm the exemption matches, then re-test after the next content update - content releases change URL categories and that is when these regress.

Why: forward proxy terminates the client's TLS session and re-originates a new one to the server, so the server's mutual-TLS challenge is answered by the firewall rather than by the client. Unless the PAN-OS release explicitly supports relaying a client certificate in forward proxy, the server sees a session with no client identity and rejects it. The hotspot test proves the path is the cause, not the vendor.

Options:

1. No-decrypt rule for that destination and port (destination address/EDL or application), above the decrypt rule, with a documented compensating control (endpoint protection, restricted source group). This is the pragmatic answer.
2. Exemption list entry if the endpoint is reached by a hostname the firewall can identify as an application.
3. Restructure so the endpoint is not in the decryption path at all (dedicated source-based no-decrypt for the integration subnet, or an outbound proxy for that service).

Do not disable decryption globally, and do not "fix" it by turning off certificate validation for everyone. Record the exemption with an owner and an expiry date so it is revisited at the next PAN-OS upgrade, when relaying support may change.

• Diagnosis: the bottleneck is TLS handshake/crypto capacity on the dataplane, not bandwidth. 09:00-11:00 is handshake-heavy (full handshakes on new sessions, poor session reuse). Check per-DP resource monitor output, decrypt session counts, and decryption log reason codes - reasons like unsupported cipher/version tell you whether sessions are being decrypted or silently passed, and whether rejected handshakes are causing client retries that multiply the load.
• Narrow the scope: decrypt the categories that need content inspection and drop bulk categories (streaming media, software updates, backups) from the decrypt rule. The video-heavy site is the clue: bulk high-throughput categories consume handshake and crypto budget for near-zero inspection value.
• Check the decryption profile: blocking unsupported versions and ciphers converts failures into error pages and retries. During rollout, pass-through for a defined period is usually the better trade; tighten later and measure.
• Distribution: confirm no single application dominates one DP; if it does, spread egress across interfaces or use policy to split sources.
• Structural: re-size the platform on decryption throughput, not firewall throughput. If 40% of egress is to be decrypted at peak, a PA-3220-class box is likely the wrong place for it - move egress decryption to a larger chassis rather than reducing coverage.