Palo Alto Networks SSL Forward Proxy Explained

Introduction

This article provides a comprehensive explanation of Palo Alto Networks SSL Forward Proxy, a critical feature for securing modern networks where SSL/TLS encryption is pervasive. We will cover its purpose, mechanism, configuration elements, and important considerations, including exemptions and exam-relevant points.

What is SSL Forward Proxy?

SSL Forward Proxy, also known as Outbound Decryption, is a Palo Alto Networks firewall feature designed to decrypt and inspect SSL/TLS encrypted traffic originating from internal clients destined for external servers (like websites, SaaS applications, etc.). With over 95% of internet traffic now encrypted, visibility into this traffic is essential for effective security.

Without SSL Forward Proxy, the firewall sees only an encrypted stream, typically identified as App-ID ssl or tls . This severely limits the effectiveness of various security features:

Accurate App-ID: Cannot identify the true application within the tunnel (e.g., differentiating facebook-posting from google-drive-upload ).
Threat Prevention: Cannot scan encrypted content for malware, exploits, or command-and-control traffic.
Granular URL Filtering: Restricted to filtering based only on the domain name (SNI), not the full URL path or parameters within HTTPS.
File and Data Filtering: Cannot inspect encrypted files or data streams for sensitive information (DLP).
Application-Based Policies: Cannot enforce granular policies based on the specific application running within the encrypted session.

     SSL Forward Proxy provides visibility into encrypted outbound traffic, enabling full Next-Generation Firewall capabilities like App-ID, Threat Prevention, URL Filtering, and DLP. It's the counterpart to SSL Inbound Inspection.
    

By decrypting outbound traffic, the firewall regains the ability to apply full security inspection, significantly enhancing the network's security posture.

Core Concepts: How SSL Forward Proxy Works & Certificates

How SSL Forward Proxy Works: The MITM Mechanism

SSL Forward Proxy operates as a Man-in-the-Middle (MITM) between the internal client and the external server. Unlike Inbound Inspection, which requires the server's private key, Forward Proxy uses a certificate-based approach.

Here's the process:

Client Initiates Connection: An internal client attempts to connect to an external HTTPS site (e.g., https://example.com ).
Firewall Intercepts: A Decryption Policy rule configured for SSL Forward Proxy matches the session.
Firewall Connects to Server: The firewall initiates its own separate SSL/TLS connection to the actual external server ( example.com ). It validates the server's real certificate.
Firewall Generates Certificate: The firewall dynamically creates a new SSL certificate that mimics the identity of the original server's certificate (copying attributes like Common Name, Subject Alternative Names).
Firewall Signs Certificate: The firewall signs this newly generated certificate using the private key of a special Certificate Authority (CA) certificate stored on the firewall and designated as the Forward Trust CA .
Firewall Presents Certificate to Client: The firewall presents this firewall-signed certificate to the internal client instead of the real server's certificate.
Client Verification: The client's browser/OS checks if the CA that signed the presented certificate (the firewall's Forward Trust CA) is trusted.
If Trusted: The client accepts the certificate, and the SSL/TLS handshake completes successfully between the client and the firewall . Decryption proceeds.
If Not Trusted: The client's browser will display a prominent certificate warning/error, potentially blocking the connection. This underscores the critical need to deploy the Forward Trust CA to client trust stores.
Decryption and Inspection: With two separate SSL sessions established (Client<->Firewall and Firewall<->Server), the firewall decrypts client traffic, inspects it using its security engines, re-encrypts it using the session key from the connection to the real server, and forwards it. Return traffic follows the reverse path.

Simplified sequence diagram showing the SSL Forward Proxy (MITM) process.

Certificates Needed for SSL Forward Proxy

Implementing SSL Forward Proxy requires specific certificates:

Forward Trust Certificate Authority (CA):
- This is a private CA certificate generated on the firewall itself (or imported if using an internal PKI).
- Its private key is used by the firewall to sign the dynamically generated certificates for external websites.
- This CA certificate MUST be deployed to the trusted root certificate stores of all internal clients whose traffic you wish to decrypt. If it's not trusted by the client, the MITM process fails with a certificate error.
Forward Untrust Certificate Authority (CA):
- This is also typically a private CA certificate generated on the firewall.
- It is used by the firewall to sign substitute certificates for sessions that FAIL certificate validation against the client's trust store (e.g., invalid certificate, expired certificate, unknown CA).
- Clients should NOT trust this CA . When a client receives a certificate signed by the Forward Untrust CA, its browser/OS should trigger a severe certificate error (e.g., "This connection is not private"). This is the desired behavior to alert the user to a potentially malicious or misconfigured site that would otherwise go unnoticed if just blocked.
- This CA certificate does NOT need to be deployed to clients . The client's default lack of trust is the intended behavior.
Default/Intermediate Certificates (Optional but Recommended):
- PAN-OS comes with a default certificates.
- You can generate or import separate certificates for the Forward Trust and Forward Untrust roles for better management.
- Using intermediate CAs can be part of a larger PKI strategy.

     Key distinction for the exam: The Forward Trust CA must be deployed to clients; the Forward Untrust CA must NOT be trusted by clients (it's used to generate invalid certs for sessions failing server validation).
    

Configuration: Decryption Policy

Decryption Policy and Rules

The Decryption Policy determines which sessions are subjected to SSL inspection. It functions much like the Security Policy, using criteria to match traffic and then applying a decryption action.

Flowchart showing how Decryption Policy interacts with Security Policy.

Decryption Policy rules have a top-down matching order, similar to Security Policy. The first rule that matches a session's criteria determines the decryption action.

     Decryption policy rules are processed BEFORE Security policy rules. Decrypting traffic enables deeper inspection *by* the Security Policy. A session that is Blocked in Decryption Policy never hits the Security Policy.
    

Decryption Policy Parameters

A Decryption Policy rule is defined by several components:

Name: A descriptive name for the rule.
Type:
- SSL Forward Proxy: Used for decrypting outbound client-to-server traffic. This is the focus of this article.
- SSL Inbound Inspection: Used for decrypting inbound client-to-server traffic where the firewall has the server's private key.
- SSL Protocol Settings: Applies settings based on protocol versions/cipher suites, often used for control or blocking without full decryption.
Source:
- Source Zone: Typically the internal zone(s) where clients reside.
- Source Address: Specific client IP addresses, ranges, or address groups.
- Source User: Users or user groups (requires User-ID).
Destination:
- Destination Zone: Typically the external (Untrust/WAN) zone.
- Destination Address: Specific server IP addresses, ranges, or address groups (less common for general outbound decryption, but useful for specific sites).
- Destination URL Category: Matches based on URL categories (e.g., match 'Business and Economy', exclude 'Financial Services'). This is a very common and powerful way to define decryption scope.
Service:
- Service: Typically service-https (TCP/443). Can include other custom services if SSL/TLS runs on non-standard ports.
Action:
- Decrypt: Enable decryption for matching traffic. When selecting this for SSL Forward Proxy, you must also select a Decryption Profile .
- No Decrypt: Explicitly skip decryption for matching traffic. This is used for sites that break decryption, contain sensitive information, or for compliance reasons (e.g., banking sites).
- Block: Block the session immediately. No further processing occurs for this session. Useful for blocking known malicious or unwanted encrypted connections entirely.
- For exam purposes, understand the difference between No Decrypt (allow encrypted) and Block (prevent connection).
Decryption Profile: (Required when Action is Decrypt) Specifies how decryption is performed and what errors are tolerated. (Covered in the next section).
Security Profiles: (Optional, applies *before* decryption) You can apply specific security profiles (like Vulnerability Protection or DoS Protection) to the initial handshake if needed, though most inspection happens post-decryption via the Security Policy.

     Order matters! Place 'No Decrypt' rules for sensitive or problematic sites HIGHER than general 'Decrypt' rules.
    

Configuration: Decryption Profile

Decryption Profile and Control

While the Decryption Policy determines *which* sessions are decrypted (or not), the Decryption Profile determines *how* the decryption process behaves , specifically regarding handling TLS protocol settings and certificate validation errors.

A Decryption Profile is a collection of settings applied to sessions matched by a Decryption Policy rule with the Action set to 'Decrypt'. It provides granular control over the decryption session based on potential issues encountered during the TLS handshake or certificate validation.

Flowchart illustrating the role and controls within a Decryption Profile.

Decryption Profile Parameters

A Decryption Profile allows configuration of actions for various certificate and protocol status outcomes. Key sections typically include:

SSL Protocol Settings

TLS Versions: Define the minimum and maximum TLS versions allowed ( SSLv3 , TLSv1.0 , TLSv1.1 , TLSv1.2 , TLSv1.3 ). Older versions like SSLv3, TLSv1.0, and TLSv1.1 are insecure and should typically be blocked or alerted.
Focus on knowing insecure protocols (SSLv3, TLSv1.0, TLSv1.1) and the recommended actions (Block or Reset).
Cipher Suites: Control which encryption cipher suites are permitted. Often, you'll block weak or null ciphers.
Action for Unsupported Version/Cipher: What happens if the client/server tries to negotiate a blocked protocol version or cipher suite (usually Block or Reset).

Certificate Validation Checks

For each of the following checks, you can typically configure different actions (Allow, Block, Reset) based on the validation status:

Invalid Certificate: The certificate is structurally invalid or malformed.
- Recommended Action: Block or Reset. Never allow.
Untrusted CA: The server's certificate is signed by a CA not present or not trusted in the firewall's trust store.
- Recommended Action: Block or Reset. The firewall *validates the server's real certificate*. If it's signed by an untrusted CA, it's suspicious. This is different from the client trusting the *firewall's* Forward Trust CA.
Expired Certificate: The server's certificate has passed its validity period.
- Recommended Action: Block or Reset. Expired certificates indicate poor maintenance or potential malicious activity.
Certificate Revoked: The server's certificate has been revoked (checked via CRL or OCSP).
- Recommended Action: Block or Reset.
Certificate Status Unknown: The firewall could not determine the revocation status (e.g., cannot reach CRL/OCSP server).
- Exam Relevance: You need to know the implications of allowing or blocking unknown status. Allowing might miss revoked certs. Blocking might block legitimate sites if OCSP/CRL infrastructure is down.
Certificate Name Mismatch: The hostname the client requested (SNI or common name in older TLS) does not match the Common Name or Subject Alternative Names in the server's certificate.
- Recommended Action: Block or Reset. A mismatch is often a sign of a misconfigured server or, more importantly, a phishing or malicious site attempting to use a certificate for a different domain.

Other Settings

Forward Untrust Certificate: This setting within the profile specifies which specific certificate (typically the firewall's Forward Untrust CA certificate) is used to sign the substitute certificate presented to the client when any of the above certificate validation checks fail and the profile action is configured to use the Forward Untrust certificate.
Passthrough (Fail Open): In some older PAN-OS versions or specific configurations, there might be an option to "pass through" traffic if decryption fails for certain reasons. This is generally NOT recommended as it bypasses security inspection. The modern approach is to Block or Reset on failure.

     Understand the actions (Allow, Block, Reset, Forward Untrust) and when each applies based on certificate validation status and protocol settings.
    

Exemptions & Updates

Exemption Mechanisms for SSL Decryption

While the goal is to decrypt as much traffic as possible, certain types of SSL-encrypted communication must be exempted from decryption for functional, security, or privacy reasons.

Common reasons and mechanisms for exemption include:

"No Decrypt" Policy Rule:
- This is the primary administrative method. You create Decryption Policy rules above your 'Decrypt' rules.
- Match criteria (Source, Destination, User, URL Category, Service) are used to identify traffic that should NOT be decrypted.
- Action is set to No Decrypt . The session is allowed to proceed encrypted.
- Commonly used for financial sites, healthcare sites, sensitive internal resources (if traffic hairpinning through the firewall), or applications known to break decryption.
Predefined Decryption Exclusions List:
- Palo Alto Networks maintains a built-in list of critical applications and services that are exempted from decryption by default and cannot be decrypted even if a policy rule matches .
- This list includes services where decryption is known to break functionality (e.g., certain update services, collaboration tools with embedded crypto), applications that use client-certificate authentication (which conflicts with MITM), or services for which decryption would be highly controversial or illegal (e.g., certificate revocation checks themselves, certain OS updates).
- This list is updated dynamically.
- You cannot remove entries from this predefined list.
Client Certificate Authentication:
- Sites that require the client browser to present a certificate for authentication.
- The MITM process breaks this because the firewall cannot obtain the client's private key to present the correct certificate to the server.
- Such sessions are typically identified and exempted automatically by the firewall.
Untrusted Server Certificate:
- If the firewall itself, when connecting to the server, determines the server's certificate is invalid (e.g., signed by an untrusted public CA, expired, name mismatch), the session may be handled based on the Decryption Profile settings.
- If the profile action is Block or Reset, the session is prevented.
- If the profile action is configured to use the Forward Untrust certificate, the firewall attempts to present that to the client, resulting in a client-side error if the Forward Untrust CA is not trusted (the desired outcome). In some failure scenarios, the session might be implicitly exempted from full inspection.
Unsupported Protocol/Cipher:
- If the client and server attempt to negotiate an SSL/TLS version or cipher suite that is explicitly blocked by the Decryption Profile.
- The action defined in the profile (typically Block or Reset) is applied, preventing decryption and usually the connection itself.

     Know the difference between *policy-based* 'No Decrypt' rules (administrator configured) and *built-in/dynamic* exemptions (Palo Alto Networks list or protocol failures).
    

Dynamic Exemption Updates

The list of applications and services that should be exempted from decryption is not static. Palo Alto Networks continuously researches applications and identifies those that break when decrypted or require exemption for other reasons (security, compliance, functionality).

The Decryption Exemption list is part of the Applications and Threats content update (also known as App-ID and Threat signatures). When you install a new version of this content pack:

It includes updates to App-ID signatures.
It includes updates to Threat signatures.
It also includes updates to the built-in Decryption Exclusions List.

This means that enabling or disabling decryption for specific applications or services might change automatically when you install a content update. The firewall uses the most current list provided by the update.

     Decryption exclusions are tied to the App/Threat content updates. Keep your content updates current!
    

The type of update is essentially an addition or modification to an internal database on the firewall that flags certain known applications/services as requiring exemption from SSL decryption, overriding even an explicit 'Decrypt' policy rule that might match the traffic.

This dynamic update mechanism ensures that the firewall can decrypt as much traffic as possible while minimizing disruption to applications that are incompatible with decryption or require specific handling.

PCNSE Focus: Key Notes & Gotchas

PCNSE/PCNSA Exam Notes on SSL Forward Proxy

SSL Decryption, particularly Forward Proxy, is a heavily tested topic on Palo Alto Networks certification exams. Here are some key points to focus on:

Purpose: Why decrypt? What visibility/capabilities does it enable? (App-ID, Threat, URL, DLP). What's the default if not decrypted? (App-ID ssl/tls).
MITM Mechanism: Understand the basic steps - Firewall intercepts, connects to server, generates certificate, signs with Forward Trust CA, presents to client.
Certificates: Know the roles of Forward Trust CA and Forward Untrust CA. Critical: Forward Trust CA must be deployed/trusted on clients. Forward Untrust CA should NOT be trusted on clients.
Decryption Policy: How it works (top-down matching), key parameters (Source, Dest, Service, URL Cat), and Actions (Decrypt, No Decrypt, Block) .
Policy Order: 'No Decrypt' rules must be higher (more specific) than 'Decrypt' rules.
Decryption Profile: Controls *how* decryption handles protocol versions, cipher suites, and certificate validation errors.
Profile Actions: Understand the meaning of Block, Reset, Allow, and using the Forward Untrust certificate for validation failures.
Key Profile Checks: Focus on Invalid Certificate, Untrusted CA, Expired Certificate, Certificate Name Mismatch, Certificate Status Unknown, and blocking insecure TLS versions (SSLv3, TLSv1.0, TLSv1.1). Name Mismatch is a common exam scenario.
Exemptions: Distinguish between administrator-configured 'No Decrypt' policy rules and the built-in, non-configurable Decryption Exclusions List .
Dynamic Updates: Decryption Exclusions are part of the Applications and Threats content update .
Troubleshooting: Common issues involve clients not trusting the Forward Trust CA (certificate errors in browser), applications breaking due to decryption (requires 'No Decrypt' rule or checking exclusions), or firewall resource limitations (though less common for basic concepts).

Scenario Example for Exam:

A user reports certificate errors when visiting banking sites, but other sites work fine with decryption. What is the most likely cause and solution?

Likely Cause: The banking site is likely matching a general 'Decrypt' rule instead of being explicitly exempted.

Solution: Create a 'No Decrypt' Decryption Policy rule for the banking site's URL category or domain, placed higher than the general 'Decrypt' rule.

      Recognize scenarios where specific sites/categories need 'No Decrypt' and the correct policy order.
     

PCNSE Focus: Interactive Quiz

Test Your Knowledge on SSL Forward Proxy

Answer the following 20 questions covering common concepts and potential exam topics related to Palo Alto Networks SSL Forward Proxy.

1. What is the primary purpose of SSL Forward Proxy on a Palo Alto Networks firewall?

To protect internal servers from encrypted attacks. To inspect encrypted outbound traffic from internal clients. To secure VPN connections using SSL/TLS. To encrypt traffic between firewalls in a High Availability pair.

Correct Answer: b
SSL Forward Proxy (Outbound Decryption) focuses on decrypting traffic initiated by internal clients towards external destinations for inspection.

2. Without SSL decryption, what App-ID is typically assigned to most encrypted web traffic?

http web-browsing ssl or tls unknown

Correct Answer: c
When traffic is encrypted and not decrypted, the firewall can typically only identify the protocol wrappers, resulting in the App-ID 'ssl' or 'tls'.

3. Which feature is enabled by decrypting SSL/TLS traffic?

Threat Prevention, URL Filtering, and Data Filtering. GlobalProtect VPN functionality. Policy Based Forwarding (PBF). High Availability (HA) synchronization.

Correct Answer: a
Decryption provides visibility into the content, which is necessary for scanning for threats (Threat Prevention), filtering specific URLs (URL Filtering), and preventing data exfiltration (Data Filtering/DLP).

4. Which certificate must be deployed to the trusted root store on client machines for SSL Forward Proxy to work without certificate errors?

The external web server's actual certificate. The firewall's management certificate. The Forward Untrust CA certificate. The Forward Trust CA certificate.

Correct Answer: d
The firewall signs forged certificates using the Forward Trust CA. Clients must trust this CA for the handshake to complete without errors.

5. The firewall uses the Forward Untrust CA certificate to sign substitute certificates when...?

The client presents an invalid certificate for authentication. The server's actual certificate fails validation checks (e.g., untrusted CA, expired, name mismatch). The client attempts to connect using an insecure TLS version. The Decryption Policy action is set to 'No Decrypt'.

Correct Answer: b
The Forward Untrust CA is used to generate invalid certificates for clients when the firewall detects issues with the server's real certificate, prompting the client to show a security error.

6. In the Decryption Policy, which action allows encrypted traffic to pass through without inspection?

Decrypt Block No Decrypt Reset

Correct Answer: c
The 'No Decrypt' action explicitly tells the firewall to skip decryption and allow the encrypted session to continue.

7. You want to exempt banking sites from decryption. Where should the policy rule for banking sites be placed relative to a general 'Decrypt All' rule?

Below the 'Decrypt All' rule. Above the 'Decrypt All' rule. In a separate policy list. The order doesn't matter for 'No Decrypt' rules.

Correct Answer: b
Decryption Policy rules are evaluated top-down. A 'No Decrypt' rule for specific sites must be placed higher than a broader 'Decrypt' rule to match first.

8. What is the primary function of a Decryption Profile?

To define how the firewall handles certificate errors and protocol versions during decryption. To specify which users and applications should be decrypted. To select which CA certificate is used for signing. To manage the list of decryption exemptions.

Correct Answer: a
The Decryption Profile contains settings for protocol versions (TLS versions, ciphers) and certificate validation checks (invalid, untrusted CA, expired, etc.) and the actions to take when issues are found.

9. Which action in a Decryption Profile should be configured for insecure SSL/TLS versions like SSLv3 and TLSv1.0?

Allow Warn Block or Reset Forward Untrust

Correct Answer: c
Insecure or deprecated protocol versions like SSLv3, TLSv1.0, and TLSv1.1 should be blocked or reset to prevent using weak encryption.

10. A user visits a site and gets a browser warning saying "This connection is not private" with details indicating an untrusted root CA, even though the Forward Trust CA is deployed. Investigation shows the firewall allowed the session but used the Forward Untrust CA certificate. What is the likely reason?

The user's client machine needs a content update. The firewall has a general 'No Decrypt' rule for the site. The site is on the built-in decryption exclusion list. The server's actual certificate failed validation based on the Decryption Profile settings.

Correct Answer: d
When the server's real certificate is invalid (e.g., untrusted CA, expired, name mismatch) and the Decryption Profile is configured to use the Forward Untrust CA for such failures, the firewall presents a certificate signed by Forward Untrust CA to the client, triggering the browser error.

11. A session is implicitly exempted from decryption even if a 'Decrypt' policy rule matches. Which of the following is a common reason for this built-in exemption?

The application uses client certificate authentication. The destination is a financial website. The user is a member of a specific user group. The traffic is destined for a non-standard port (e.g., TCP 8443).

Correct Answer: a
Applications using client certificate authentication are typically incompatible with the MITM process of SSL Forward Proxy and are automatically exempted. Financial sites and user groups are usually handled by policy, and non-standard ports can often still be decrypted if the service is defined.

12. Where does Palo Alto Networks maintain the list of predefined decryption exclusions that cannot be modified by the administrator?

In the Decryption Profile settings. In the Decryption Policy, marked with a lock icon. As part of the Applications and Threats content updates. In a separate configuration file that can only be modified by TAC.

Correct Answer: c
The built-in, non-modifiable list of decryption exclusions is distributed as part of the regular Applications and Threats content updates.

13. What happens if a session matches a Decryption Policy rule with the action set to 'Block'?

The traffic is allowed encrypted, and logged. The session is immediately terminated and blocked, without hitting the Security Policy. The traffic is decrypted, inspected, and then blocked by the Security Policy. The firewall presents a Block page to the user.

Correct Answer: b
A 'Block' action in the Decryption Policy is a hard block that occurs before Security Policy evaluation. The session is dropped.

14. What is the recommended action in a Decryption Profile when a server certificate exhibits a Name Mismatch (common name/SAN doesn't match requested hostname)?

Allow Allow, but log a warning. Block or Reset. Forward Untrust (if configured to use Forward Untrust CA).

Correct Answer: c
A certificate name mismatch is a strong indicator of a potential security risk (phishing, misconfiguration). Blocking or resetting the connection is the recommended secure action. While 'Forward Untrust' might be used in some setups, Block/Reset is generally preferred for this specific failure type.

15. If the Decryption Profile is configured to 'Block' sessions with an 'Untrusted CA' (referring to the server's CA), and a user visits a site using a self-signed certificate that is not trusted by the firewall, what will happen?

The session will be blocked by the firewall's decryption engine. The firewall will attempt to decrypt it and pass it to the Security Policy. The firewall will present a certificate signed by the Forward Trust CA to the client. The session will be allowed encrypted without inspection.

Correct Answer: a
The Decryption Profile defines actions for certificate validation failures. If the profile is set to 'Block' for Untrusted CA, the firewall will block the session when it encounters a server certificate signed by a CA it doesn't trust.

16. A user reports that a specific application, verified to be allowed in the Security Policy, stops working when you enable SSL decryption. What is a common first step in troubleshooting?

Reinstall the Forward Trust CA on the client. Change the Decryption Policy action for all traffic to 'No Decrypt'. Check if the application is on the built-in Decryption Exclusions List or create a 'No Decrypt' policy rule for it. Increase the session timeout for the application.

Correct Answer: c
Some applications are incompatible with decryption. Checking the built-in exclusion list or creating a targeted 'No Decrypt' policy rule for the application is the standard first troubleshooting step.

17. When the firewall acts as an SSL Forward Proxy, how many separate SSL/TLS sessions are typically involved for a single client connection to a server?

One (Client directly to Server). Two (Client to Firewall, Firewall to Server). Three (Client to Firewall, Firewall to Server, and a separate inspection session). Four (One for each direction between Client-Firewall and Firewall-Server).

Correct Answer: b
The MITM approach involves two distinct SSL/TLS sessions: one between the client and the firewall, and another between the firewall and the server.

18. What type of content update includes updates to the built-in Decryption Exclusions List?

Antivirus WildFire URL Database Applications and Threats

Correct Answer: d
The Decryption Exclusions List is part of the Applications and Threats content updates, alongside App-ID and Threat signatures.

19. You are configuring a Decryption Policy rule for SSL Forward Proxy. Which of the following is a mandatory setting when the Action is set to 'Decrypt'?

Decryption Profile SSL Protocol Settings Forward Untrust CA Certificate Security Profiles

Correct Answer: a
When you set the action to 'Decrypt' in a Decryption Policy rule, you must select a Decryption Profile to define the specifics of how decryption should be handled.

20. When the firewall generates a certificate during the SSL Forward Proxy process, which information is copied from the server's actual certificate?

The server's private key. The expiration date and the server's public key. The signing Certificate Authority information. Attributes like Common Name and Subject Alternative Names.

Correct Answer: d
The firewall creates a new certificate mimicking the server's identity by copying attributes like Common Name and Subject Alternative Names. It does not copy the private key or use the server's CA information; it signs the *new* certificate with its own Forward Trust CA's private key.