PAN-OS: Configuring SSL Inbound Inspection

What is SSL Inbound Inspection?

SSL Inbound Inspection is a feature on Palo Alto Networks firewalls that allows the firewall to decrypt and inspect SSL/TLS traffic destined for internal servers (e.g., internal web servers, application servers) hosted behind the firewall. By decrypting this incoming traffic, the firewall gains visibility into the application and content within the encrypted session.

This visibility is essential for applying effective security measures, including:

This is distinct from SSL Forward Proxy (Outbound Inspection), where the firewall decrypts traffic initiated by internal clients going to external websites.

Core Concept: Man-in-the-Middle (MITM) with Server's Key

SSL Inbound Inspection works by placing the firewall in a Man-in-the-Middle (MITM) position between the external client and the internal server.

Critical Requirement: For the firewall to successfully decrypt the incoming session and impersonate the internal server to the external client, it MUST possess the internal server's actual SSL/TLS certificate AND its corresponding private key .

  1. An external client initiates an SSL/TLS connection to the public IP address associated with the internal server (this might be a NAT address or the firewall interface).
  2. The firewall intercepts this connection attempt (based on a matching Decryption Policy rule).
  3. The firewall uses the imported server certificate and private key to complete the SSL/TLS handshake with the external client, essentially pretending to be the real server.
  4. Simultaneously, the firewall initiates a *separate* SSL/TLS connection to the *actual* internal server (using standard certificate validation).
  5. The firewall now sits in the middle, decrypting traffic from the client, inspecting it, re-encrypting it, and sending it to the server (and vice-versa for the return traffic).

This allows the firewall's security engines (App-ID, Threat Prevention, etc.) to inspect the clear-text application data flowing between the client and the server.

Prerequisites

Before configuring SSL Inbound Inspection, ensure these are available:

Configuration Steps

  1. Import Server Certificate and Private Key:

    • GUI Path: Device > Certificate Management > Certificates
    • Click Import .
    • Certificate Name: Give it a descriptive name (e.g., `WebServer-Prod-Cert`).
    • Select the Certificate File (usually PEM or PKCS12 format).
    • Check the box `Import Private Key` .
    • Select the corresponding Private Key File (if separate) or provide the passphrase if the key is encrypted or part of a PKCS12 bundle.
    • Do NOT check `Mark Private Key Exportable` unless absolutely necessary for specific, documented reasons. Leaving it unchecked enhances security.
    • Click OK. Verify the certificate shows "Valid" and includes a private key icon.
    • Import any necessary Intermediate/Root CA certificates if they are not already trusted by the firewall.
  2. Create a Decryption Profile (Optional but Recommended):

    • GUI Path: Objects > Decryption > Decryption Profile
    • Click Add .
    • Name: e.g., `Inbound-Decrypt-Profile`.
    • SSL Decryption Tab > SSL Inbound Inspection Tab: Configure options for handling unsupported modes, certificate checks, session limits, etc. Often, default settings are acceptable for basic inbound inspection, but review options based on security requirements.
    • Click OK.
  3. Create a Decryption Policy Rule:

    • GUI Path: Policies > Decryption
    • Click Add .
    • Name: e.g., `Decrypt-Internal-WebServer`.
    • Source Tab: Define Source Zone(s) (e.g., `Untrust`) and Source Address(es) (`any` or specific external ranges).
    • Destination Tab:
      • Define Destination Zone (where the server resides *logically* before NAT, often the external zone if using DNAT, or the internal zone if using a Layer 3 interface IP).
      • Destination Address: Enter the Public IP address that external clients connect to. This is often a VIP address on the firewall or an address used in a Destination NAT rule.
    • Service/URL Category Tab:
      • Service: Typically set to service-https or a custom service object for TCP/443.
      • URL Category: Generally left as `any` for inbound inspection unless specifically needed.
    • Options Tab (Crucial):
      • Action: Select `Decrypt` .
      • Type: Select `SSL Inbound Inspection` .
      • Certificate: Select the Server Certificate (with its private key) that you imported in Step 1 (e.g., `WebServer-Prod-Cert`). This is the certificate the firewall will present to external clients.
      • Decryption Profile: Select the Decryption Profile created in Step 2 (e.g., `Inbound-Decrypt-Profile`).
    • Click OK.
    • Ensure the rule is placed appropriately (top-down processing).
  4. Configure Supporting Security Policy:

    • Ensure a Security Policy rule exists ( Policies > Security ) that allows the initial HTTPS connection.
    • Example: Source Zone `Untrust`, Dest Zone `DMZ`, Destination Address (Internal Server IP *Before* pre-nat NAT), Application `ssl`, Service `service-https`, Action `Allow`.
    • Attach desired Security Profiles (Threat Prevention, File Blocking, etc.) to this Security rule. These profiles will inspect the decrypted content.
  5. Configure Destination NAT (If Necessary):

    • If clients connect to a public IP different from the server's internal IP, configure a Destination NAT rule ( Policies > NAT ).
    • Match traffic destined for the Public IP on the External Zone.
    • Translate the Destination IP to the Internal Server's Private IP address.
    • The Decryption Policy rule matches the *original* (public) destination IP, The security policy also uses the pre-nat IP addres
  6. Commit Changes:

    Commit the configuration to the firewall.

Visualization

graph LR
    Client[External Client] -- 1. HTTPS Request to Public IP --> FW(Firewall);
    subgraph Firewall
        DecPol{Decryption Policy
Matches Public IP,
Action: Decrypt,
Type: SSL Inbound,
Cert: Server Cert+Key
} -- Applies --> Traffic; FW_Engines(Inspection Engines
App-ID, Threat Prev,
File Block, URL Filt) -- Inspect Decrypted --> Traffic; SecPol{Security Policy
Allows 'ssl' or
Decrypted App-ID,
Applies Profiles
} -- Applies --> Traffic; NATPol{DNAT Policy
Translates Public IP
to Private IP
} -- Applies --> Traffic_PostNAT; end FW -- 2. Impersonates Server
(Uses Server Cert+Key) --> Client; FW -- 3. Initiates New SSL
(Cleartext Internally) --> IntServer(Internal Server
Private IP); Client <-. Encrypted Session .-> FW; FW <-. Cleartext for Inspection .-> FW_Engines; FW <-. Potentially Re-Encrypted .-> IntServer; linkStyle 0 stroke:#007bff,stroke-width:1px; linkStyle 1 stroke:#dc3545,stroke-width:2px,color:red; linkStyle 2 stroke:#28a745,stroke-width:1px,color:green; linkStyle 3 stroke:#ffc107,stroke-width:1px,color:orange; linkStyle 4 stroke:#17a2b8,stroke-width:1px,color:teal; linkStyle 5 stroke:#007bff,stroke-width:1px; linkStyle 6 stroke:#6c757d,stroke-width:1px,stroke-dasharray: 5 5; linkStyle 7 stroke:#6c757d,stroke-width:1px,stroke-dasharray: 5 5; linkStyle 8 stroke:#6c757d,stroke-width:1px,stroke-dasharray: 5 5;
Simplified SSL Inbound Inspection Flow.

Impact and Benefits

Caveats, Gotchas, and Considerations

Best Practices

PCNSE Exam Focus

For the PCNSE exam, regarding SSL Inbound Inspection:

Clarification: Decryption and Security Policy Matching with DNAT

Regarding traffic subject to Destination NAT (DNAT), specifically for features like SSL Inbound Inspection, it's essential to understand which IP address the different policy engines use for matching:

Policy Matching Summary (with DNAT):

Policy Type Destination IP Used for Matching
NAT Policy (Destination NAT) Original Destination IP (Public IP)
Decryption Policy Original Destination IP (Public IP)
Security Policy Original Destination IP (Public IP)

Conclusion: Both Decryption Policy and Security Policy match on the Original (Pre-NAT) Destination IP address when evaluating incoming traffic, even when a Destination NAT rule applies.

Clarification: Decryption and Security Policy Matching - Destination Zone with DNAT

When considering Destination NAT (DNAT) for inbound traffic (e.g., external clients connecting to an internal server via a public IP), the Destination Zone used for policy matching follows the principle of evaluating the original packet context:

Zone Matching Summary (with DNAT for Inbound Traffic):

Policy Type Source Zone Used for Matching Destination Zone Used for Matching
Decryption Policy Ingress Interface Zone (e.g., `Untrust`) Ingress Interface Zone (e.g., `Untrust`)
Security Policy Ingress Interface Zone (e.g., `Untrust`) Ingress Interface Zone (e.g., `Untrust`)

Conclusion: For inbound traffic subject to DNAT, both Decryption and Security Policies match based on the Pre-NAT Destination Zone context, which is typically the zone of the interface where the traffic arrives.

SSL Inbound Inspection Quiz

1. What is the primary goal of configuring SSL Inbound Inspection?

SSL Inbound Inspection specifically targets traffic coming from external clients towards internal servers, allowing the firewall to inspect the encrypted content for threats or policy enforcement.

2. What is the MOST critical prerequisite for the firewall to perform SSL Inbound Inspection?

To impersonate the internal server and decrypt the session, the firewall MUST possess the server's private key along with its certificate. This is the fundamental requirement differentiating it from outbound inspection.

3. In which policy type is SSL Inbound Inspection configured and enabled?

Decryption policies (Policies > Decryption) are used to define which traffic flows should be decrypted. You set the Action to 'Decrypt' and Type to 'SSL Inbound Inspection'.

4. When configuring the Decryption Policy rule for SSL Inbound Inspection, which certificate is selected in the 'Certificate' field under the rule's Options?

The firewall needs to present the *actual* server's certificate (for which it also has the private key) to the external client to successfully establish the decrypted session.

5. What is a major security implication or risk associated with SSL Inbound Inspection?

The biggest security consideration is that the firewall now holds the private keys for internal servers. Compromise of the firewall could lead to compromise of these keys, making strict control over firewall access paramount.

6. How does SSL Inbound Inspection enable more effective Threat Prevention?

Without decryption, Threat Prevention engines can only see encrypted data. By decrypting, the firewall exposes the actual application payload (e.g., file uploads, command strings) to the AV, Anti-Spyware, and Vulnerability Protection engines.

7. A Decryption Policy rule for SSL Inbound Inspection is configured to match destination IP 203.0.113.10. A DNAT rule translates 203.0.113.10 to internal server 10.1.1.50. Which IP address should the associated Security Policy rule typically match as the destination?

<
Decryption policy matches based on the original packet details (pre-NAT destination IP). Security policy evaluation happens later in the flow, typically after NAT has occurred, so it matches based on the translated Pre-nat destination IP address.

8. SSL Inbound Inspection is generally considered incompatible with which web server feature?

Because the firewall terminates the initial SSL session from the client and initiates a new one to the server, it breaks the chain required for the end server to validate a certificate presented by the client.

9. What happens if a client attempts to connect to a server protected by SSL Inbound Inspection using an SSL/TLS cipher suite that the firewall does NOT support for decryption?

The Decryption Profile allows configuration of actions for unsupported modes (ciphers, versions). Common options are to drop the connection or allow it through undecrypted (bypassing inspection).

10. Where do you import the internal server's certificate AND private key for use in SSL Inbound Inspection?

All certificates and their corresponding private keys used by the firewall (for management, decryption, VPNs, etc.) are imported and managed under Device > Certificate Management > Certificates.

References