7.1 SSL Forward Proxy Architecture and Internal Certificate Authority Trust

7.1 SSL Forward Proxy Architecture and Internal Certificate Authority Trust

Core Concept: SSL Forward Proxy enables Palo Alto Networks Next-Generation Firewalls (NGFW) to act as an intermediate transparent Man-in-the-Middle (MITM) proxy for outbound SSL/TLS traffic. By terminating external TLS handshakes and issuing dynamically generated certificates to internal endpoints, the firewall eliminates the critical security blind spot created by encrypted web traffic while maintaining enterprise trust boundaries.

The Outbound SSL/TLS Inspection Imperative

Modern enterprise networks experience an environment where over 85% to 90% of outbound web traffic is encrypted using SSL/TLS protocols. While encryption protects data privacy across untrusted public networks, it also provides an effective cover for malicious actors. Threat actors routinely leverage HTTPS to deliver malware, execute command-and-control (C2) communications, conceal data exfiltration, and obscure phishing pages.

Traditional stateful firewalls and signature-based inspection engines cannot inspect encrypted payloads without terminating the TLS session. On Palo Alto Networks NGFWs, unless SSL Decryption is enabled, core security engines—including App-ID, Content-ID, Threat Prevention (IPS/Anti-Virus/Vulnerability Protection), and WildFire—are constrained to analyzing only unencrypted outer headers, such as IP addresses, TCP ports, and unencrypted Server Name Indication (SNI) fields.

+-----------------------------------------------------------------------------------+
|                              UNINSPECTED TRAFFIC                                  |
|  [Client] ---- Encrypted HTTPS Tunnel (TLS 1.2/1.3) ----> [NGFW] ----> [Internet] |
|  * Threat Prevention Engine: BLIND                                                |
|  * Data Loss Prevention (DLP): BLIND                                              |
|  * Advanced WildFire Analysis: BLIND                                              |
+-----------------------------------------------------------------------------------+
                                         vs.
+-----------------------------------------------------------------------------------+
|                                DECRYPTED TRAFFIC                                  |
|  [Client] <-- TLS 1 --> [NGFW Forward Proxy] <-- TLS 2 --> [External Web Server]  |
|                         |-> SP3 Inspection Engine                                 |
|                             * App-ID Re-identification                              |
|                             * IPS & Antivirus Scanning                            |
|                             * DLPI & URL Filtering Enforcement                    |
+-----------------------------------------------------------------------------------+

By deploying SSL Forward Proxy, the NGFW intercepts outbound TLS sessions initiated by internal clients, decrypts the session payload, subjects the cleartext data to the Single-Pass Parallel Processing (SP3) architecture, and re-encrypts the payload before forwarding it to the destination web server.

---

Dual-Handshake Architecture & MITM Flow

The fundamental mechanic of SSL Forward Proxy relies on establishing two independent TLS handshakes for every intercepted session. The firewall effectively sits between the client and the destination server, maintaining separate cryptographic contexts for each side of the connection.

Step-by-Step Handshake Sequence

1. Client TLS Connection Initiation: An internal endpoint initiates a TLS connection to an external secure site (e.g., https://example.com) by sending a TLS ClientHello packet containing supported TLS versions, cipher suites, and the Server Name Indication (SNI) extension.
2. NGFW Interception & Decryption Policy Evaluation: The NGFW intercepts the ClientHello. The firewall evaluates active Decryption Policy Rules matching source, destination, URL category, and user identity. If the matching rule specifies the action decrypt with type ssl-forward-proxy, interception proceeds.
3. Server-Side TLS Handshake:
   • The NGFW initiates a separate TLS handshake with the target destination server (example.com) by sending its own ClientHello.
   • The destination server responds with its ServerHello, server certificate, and key exchange parameters.
   • The NGFW validates the destination server's certificate against its internal Trusted CA Certificate Store. The firewall verifies the certificate signature chain, expiration date, Subject Alternative Name (SAN), and revocation status via Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRL).
4. Dynamic Certificate Generation (Client-Side Handshake):
   • Upon successfully validating the server's certificate, the firewall dynamically creates a new X.509 certificate matching the host details (Subject Common Name and SANs) of the external server certificate.
   • The firewall signs this newly generated copy using its locally installed Subordinate CA (Forward Trust CA) private key.
   • The firewall completes the client-side TLS handshake with the internal endpoint, sending the dynamically signed certificate.
5. Encrypted Data Flow & SP3 Inspection:
   • The client verifies the firewall's signed certificate against its local trust store and establishes a symmetric TLS session key with the firewall.
   • Once both handshakes are established, cleartext application data sent by the client is decrypted by the firewall's dataplane, inspected by all configured Security Profiles (Threat Prevention, WildFire, URL Filtering, File Blocking), re-encrypted using the server-side symmetric key, and transmitted to the destination.

---

Internal Certificate Authority (CA) Integration & PKI Trust Setup

For SSL Forward Proxy to operate transparently without generating client-side browser warnings, client devices must explicitly trust the Certificate Authority that signs the firewall's dynamically generated certificates.

PKI Architecture Options

PAN-OS supports two primary enterprise Public Key Infrastructure (PKI) integration models for SSL Forward Proxy:

• Enterprise Subordinate CA (Recommended): The enterprise Root CA (such as Microsoft Active Directory Certificate Services or an Enterprise PKI) issues a Subordinate/Intermediate CA certificate specifically for the Palo Alto Networks firewall. The firewall's certificate request (CSR) must include the basic constraints extension designating Is CA = True (Path Length Constraint defined per enterprise policy). Because all corporate endpoints already trust the Enterprise Root CA, any certificate signed by the firewall's Subordinate CA is implicitly trusted by all enterprise devices.
• Self-Signed Root CA (Standalone / Lab Deployments): The PAN-OS firewall generates its own self-signed Root CA certificate directly within the Web Interface (Device > Certificate Management > Certificates). In this model, the public certificate of the firewall-generated CA must be exported and manually or automatically distributed to every internal endpoint's trust store.

Endpoint Certificate Deployment

To prevent end-user disruption, the public CA certificate used by the firewall must be installed into the Trusted Root Certification Authorities certificate store across all enterprise operating systems and browsers:

• Windows Endpoints: Deployed via Active Directory Group Policy Objects (GPO) to the Local Computer Trusted Root Certification Authorities store.
• macOS / iOS: Distributed using Mobile Device Management (MDM) profiles (e.g., Microsoft Intune, Jamf Pro).
• Linux / Android: Installed into domain/system CA trust directories (e.g., /etc/ssl/certs or /etc/pki/ca-trust).
• Third-Party Application Stores: Certain browsers (such as Mozilla Firefox) and developer runtimes (Python certifi, Java JRE cacerts, Node.js, Docker) maintain isolated trust stores separate from the operating system, requiring dedicated enterprise policy configuration or environment variable overrides (e.g., NODE_EXTRA_CA_CERTS).

---

Forward Trust Certificate vs. Forward Untrust Certificate Dynamics

PAN-OS utilizes two distinct CA certificates configured under Certificate Management to handle external server trust states dynamically:

                                  +---------------------------------------+
                                  | Valid External Server Certificate?    |
                                  +---------------------------------------+
                                                     |
                         +---------------------------+---------------------------+
                         | YES                                                   | NO
                         v                                                       v
        +----------------------------------+                   +----------------------------------+
        | Forward Trust Certificate        |                   | Forward Untrust Certificate      |
        | Signed by Firewall Trust CA      |                   | Signed by Firewall Untrust CA    |
        | Trusted by Endpoint OS/Browser   |                   | NOT Trusted by Endpoint (Warning)|
        +----------------------------------+                   +----------------------------------+
        | Result: Seamless Decrypted Flow  |                   | Result: Browser Security Warning |
        +----------------------------------+                   +----------------------------------+

1. Forward Trust Certificate

• Usage Condition: The firewall successfully validates the destination server's certificate against its trusted CA list. The server certificate is valid, current, unrevoked, and matches the requested domain.
• Mechanism: The firewall signs the dynamically generated client-facing certificate using the private key associated with the Forward Trust Certificate.
• Client Experience: The client's browser validates the signature chain up to the trusted Enterprise Root CA. The HTTPS connection displays a secure padlock icon without any certificate warnings.

2. Forward Untrust Certificate

• Usage Condition: The destination server presents an untrusted, expired, self-signed, revoked, or hostname-mismatched SSL/TLS certificate.
• Mechanism: The firewall signs the dynamically generated client-facing certificate using the private key of the Forward Untrust Certificate.
• Client Experience: The Forward Untrust Certificate public key is intentionally NOT distributed to client endpoints. Consequently, the user's browser displays a prominent red security warning (NET::ERR_CERT_AUTHORITY_INVALID or SEC_ERROR_UNKNOWN_ISSUER).
• Operational Value: This mechanism ensures that the firewall does not obscure security risks existing on external servers. If the firewall simply signed invalid external certificates with the Forward Trust CA, users would be blindly shielded from legitimate external certificate errors, creating severe security vulnerabilities.

---

TLS 1.3 Protocol Inspection & SNI Handling

The adoption of TLS 1.3 (RFC 8446) introduced key cryptographic modifications designed to improve performance and privacy, creating specific requirements for firewall inspection.

Key TLS 1.3 Changes Impacting Inspection

1. Encrypted Handshake Extensions & Certificates: Unlike TLS 1.2, where the server certificate is sent in cleartext during the handshake, TLS 1.3 encrypts the server certificate and handshake extensions immediately after the ServerHello message.
2. Encrypted Client Hello (ECH) / ESNI: Features such as Encrypted Server Name Indication obscure the target domain name in the initial ClientHello.
3. Mandatory Perfect Forward Secrecy: TLS 1.3 eliminates static RSA key exchange algorithms entirely, requiring Ephemeral Diffie-Hellman (ECDHE) key exchange for every session.

PAN-OS TLS 1.3 Implementation Strategy

To evaluate Decryption Policies before full handshake completion in TLS 1.3 environments, PAN-OS executes early Server Name Indication (SNI) extraction:

• SNI Extraction: The firewall reads the unencrypted SNI field in the initial TLS 1.3 ClientHello to match policy parameters (Source, Destination, URL Category).
• Middlebox Compatibility Mode: PAN-OS supports TLS 1.3 middlebox compatibility standards (RFC 8446 Appendix D), emitting dummy change cipher spec records to ensure seamless transit through legacy network devices.
• Fallback & Downgrade Controls: Administrators can configure Decryption Profiles to enforce minimum TLS versions (e.g., TLS 1.2) or allow controlled TLS 1.3 fallback if server-side negotiation fails or unsupported extensions are encountered.

---

Decryption Policy Rules & Decryption Profile Mechanics

Creating an effective SSL Forward Proxy architecture requires pairing Decryption Policy Rules with fine-tuned Decryption Profiles.

Decryption Policy Rule Parameters

Decryption Policy Rules determine which sessions are intercepted. Key matching criteria include:

• Source / Destination Zones & IP Addresses: Scoping inspection to specific network segments.
• URL Categories: Target high-risk categories (e.g., command-and-control, hacking, unknown, file-hosting) while bypassing sensitive categories (e.g., financial-services, health-and-medicine).
• Service: Typically service-http (port 80) and service-https (port 443), or custom TCP ports.
• Action:
  • decrypt: Intercepts traffic. Must specify Decryption Type (ssl-forward-proxy) and attach a Decryption Profile.
  • no-decrypt: Permits TLS traffic to bypass interception.

Decryption Profile Configuration Options

Decryption Profiles define how decrypted sessions are evaluated cryptographically. Configurable tabs under Objects > Decryption Profile > SSL Forward Proxy include:

• Protocol Settings:
  • Minimum & Maximum TLS Version: Restrict connections using outdated protocols (e.g., set Min TLS to Max TLS 1.2 or TLS 1.3 to automatically block insecure SSLv3, TLS 1.0, and TLS 1.1).
  • Cipher Suite Controls: Selectively enable or disable cipher algorithms (e.g., block 3DES, RC4, NULL ciphers, or non-PFS ciphers).
• Unsupported Algorithm Handling:
  • Block sessions with unsupported versions: Drops connections using TLS versions not supported by the firewall dataplane.
  • Block sessions with unsupported cipher suites: Drops connections requesting weak or unrecognized ciphers.
• Server Certificate Verification:
  • Block sessions with expired certificates: Immediately drops connections if the external server certificate has expired.
  • Block sessions with untrusted issuers: Immediately drops sessions if the external server certificate cannot be validated against the firewall's Trusted CA store.
  • Block sessions with unknown status: Drops sessions if OCSP/CRL revocation checking returns an indeterminate state.
  • Check Certificate Revocation Status using OCSP/CRL: Enables real-time revocation checking of external server certificates.

---

Technical Comparison Reference