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 (Post-NAT): Typically the zone of the ingress interface (e.g., `Untrust`).
      • Define Destination Address (Pre-NAT): Enter the Public IP address that external clients connect to.
    • Service/URL Category Tab:
      • Service: Typically set to service-https or a custom service object for TCP/443.
      • URL Category: Generally left as `any`.
    • 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`).
      • 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 based on its original context .
    • Example: Source Zone Untrust , Destination Zone Untrust , Destination Address (Public IP - Pre-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 after the Decryption policy is applied.

  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.
    • Remember: Both Decryption and Security policies match on the original (Pre-NAT) Destination IP and Zone . The DNAT rule itself also matches the original destination IP but determines the Post-NAT IP used for internal routing.

  6. Commit Changes:

    Commit the configuration to the firewall.

Visualization 

graph TD
    Client[External Client] -->|1. HTTPS Request To Public IP in Untrust Zone| Firewall(Firewall)
    Firewall --> NATPol_Lookup{"1a. DNAT Policy Lookup\nMatches Public IP\nDetermines Private IP"}
    Firewall --> DecPol{"1b. Decryption Policy Lookup\nMatches SrcZone=Untrust\nDstZone=DMZ\nDstIP=Private IP\nAction: Decrypt - SSL Inbound"}
    Firewall --> SecPol{"1c. Security Policy Lookup\nMatches SrcZone=Untrust\nDstZone=DMZ\nDstIP=Private IP\nApp=ssl\nAction: Allow"}
    
    NATPol_Lookup --> DecPol
    DecPol --> SecPol
    
    Firewall -->|2. Decrypt and Inspect| FW_Engines(Inspection Engines\nApp-ID, Threat Prev, etc.\nApplied based on SecPol)
    FW_Engines -->|3. Forward Cleartext or Re-encrypted| RouteLookup{"4. Route Lookup\nUses Private IP"}
    RouteLookup -->|Routes To| EgressIntf(Egress Interface\nZone=DMZ)
    
    Firewall -->|Handshake with Server Cert and Key| Client
    EgressIntf --> IntServer(Internal Server\nPrivate IP in DMZ Zone)
    
    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:#6f42c1,stroke-width:1px,color:purple
    linkStyle 5 stroke:#17a2b8,stroke-width:1px,color:teal
    linkStyle 6 stroke:#007bff,stroke-width:1px
    linkStyle 7 stroke:#6c757d,stroke-width:1px,stroke-dasharray: 5 5
Simplified SSL Inbound Inspection Flow with Policy Matching Clarification.

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, the Destination Zone used for policy matching follows the principle of evaluating the post-NAT 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 ) Post-NAT Zone (e.g., DMZ )
Security Policy Ingress Interface Zone (e.g., Untrust ) Post-NAT Zone (e.g., DMZ )

Conclusion: For inbound traffic subject to DNAT, both Decryption and Security Policies match based on the Post-NAT Destination Zone context, which is the zone of the internal server where the traffic terminates (e.g., DMZ ).

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 matches traffic arriving at the Untrust zone destined for Public IP 203.0.113.10. A DNAT rule translates this to Private IP 10.1.1.50 (in the DMZ zone). What Destination Zone and Destination Address should the corresponding Security Policy rule use for matching?

Corrected: Both Decryption and Security policies match based on the original packet's context before NAT translation. The traffic arrived destined for the Public IP (203.0.113.10) in the Untrust zone. Therefore, the Security Policy must match Destination Zone `Untrust` and Destination Address `203.0.113.10`.

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