How can a firewall stop a threat it cannot see? This is the exact problem that SSL/TLS decryption solves: encrypted traffic is a blind spot for traditional security tools, and in a modern network, over 90% of traffic is encrypted. For the PCNSE exam, understanding how to configure a Forward Proxy to decrypt outbound traffic is critical, as it is the primary method for regaining visibility into that encrypted blind spot without breaking the internet for your users.
Jump to a section
A simple way to picture Decryption: SSL/TLS Policy Configuration and Forward Proxy
A government building's mail room guards are the central object of this analogy. Every piece of incoming and outgoing mail must pass through this single, controlled location. The guards are the only ones with the authority to open sealed envelopes to inspect their contents before they are delivered or sent out. This is a mandatory checkpoint, not an optional one, designed to catch dangerous materials like weapons or illicit substances hidden inside an envelope that would otherwise be invisible from the outside.
In a company network, a Forward Proxy configured for SSL Decryption does exactly this. The 'mail room' is the Palo Alto Networks firewall, and the 'sealed envelopes' are encrypted HTTPS connections between an internal employee's computer and an external website like Gmail or Facebook. Normally, a firewall cannot see inside an encrypted connection; it can only see the destination address (the address on the outside of the envelope). By configuring an SSL Forward Proxy decryption policy, the firewall becomes a trusted intermediary that can 'open' the encrypted connection, inspect the traffic inside (like checking for malware or data leaks), and then re-seal it to send it on its way. The underlying process is the same: a controlled, centralised point of inspection for sealed content that is otherwise invisible.
Let's start with the core problem. When you visit a website using HTTPS (the padlock icon in your browser), the data sent between your computer and that website is encrypted. Encryption is like a secret code. Only the sender (your browser) and the intended receiver (the website's server) have the key to decode the message. This is brilliant for privacy, but it creates a massive security blind spot for a company. A firewall sitting between your computer and the internet sees the encrypted connection, but it has no idea what is inside. It is like a postal worker who can see an envelope but cannot open it to check if it contains a bomb. This is where SSL/TLS decryption comes in.
SSL/TLS decryption is the process of a security device, like a Palo Alto Networks firewall, acting as a middleman to inspect the contents of encrypted traffic. Think of it as the firewall getting a special, authorised key to open the envelope, inspect the letter, and then put it back in a new envelope that is re-encrypted with the original website's key. The end user's experience is usually invisible, provided the firewall has been configured correctly. The PCNSE exam focuses heavily on two main types of decryption: Forward Proxy and Inbound Inspection. This chapter is about Forward Proxy.
Forward Proxy decryption is used for outbound traffic. This is traffic originating from an internal user (like an employee) going out to a destination on the internet (like a web server for Salesforce or YouTube). The Palo Alto Networks firewall sits in the path of this traffic. For it to decrypt this traffic, it must interpose itself into the connection. Here is the step-by-step flow. First, the user's browser attempts to connect to, for example, https://www.example.com. The browser sends a message asking for a secure connection. Instead of letting this message go directly to example.com, the firewall intercepts it. The firewall then pretends to be the browser and opens a new, separate encrypted connection with the actual example.com server. At the same time, the firewall creates a second connection with the user's browser, pretending to be example.com.
This second connection is critical. For the user's browser to trust the firewall pretending to be example.com, the firewall must present a certificate that the browser trusts. This is why you need a Certificate Authority (CA) in the organisation. An organisation deploys its own internal root CA certificate to all managed company computers. When the firewall acts as the website, it uses this internal CA to dynamically generate a certificate for example.com on the fly. Because the root CA is trusted by the user's computer (the IT department installed it), the browser accepts this fake certificate without throwing a security warning. The traffic is now decrypted and visible to the firewall's threat prevention and data filtering engines. After inspection, the firewall re-encrypts the traffic and sends it to the actual website.
Now, how do you control what gets decrypted and what does not? You cannot and should not decrypt everything. Decrypting a banking website is illegal and breaks the terms of service. Decrypting medical or health data (like a doctor's appointment portal) may violate privacy regulations. This is where policy configuration becomes vital. In the Palo Alto Networks firewall, you configure a Decryption Profile and then a Decryption Policy Rule. The Decryption Profile defines the settings, like what to do with expired certificates or what algorithm to allow. The Decryption Policy Rule decides which traffic gets decrypted based on criteria like source zone (e.g., 'Trust'), destination zone (e.g., 'Untrust'), source IP address, destination URL category (e.g., 'Social Networking' or 'Financial Services'), and User-ID (e.g., group 'Engineering').
You would typically create rules in a specific order. A common best practise, and what the exam tests, is to create a 'No Decrypt' rule for sensitive categories like Health and Medicine, Financial Services, and Government, placed at the top of the policy. Below that, you create a 'Decrypt' rule for categories you want to inspect, like 'Social Networking', 'Email', and 'Search Engines'. At the very bottom, you normally have a catch-all 'No Decrypt' rule for everything else. The firewall evaluates rules from top to bottom; the first rule that matches the traffic wins. This hierarchy is a crucial exam concept.
Finally, consider the Decryption Profile. This profile is attached to the Decryption Policy Rule. Within it, you can configure: - 'Strip ALPN': This removes the Application-Layer Protocol Negotiation extension. Some modern websites use this to negotiate different protocols (like HTTP/2 or HTTP/3). Stripping it can force the browser to fall back to HTTP/1.1, which is easier for the firewall to inspect. - 'Block sessions with expired certificates': If a website's certificate is expired, it might be malicious. This setting will drop the connection. - 'Block sessions with untrusted issuers': If the certificate's issuer is not trusted by the firewall, drop the connection. These settings are part of the Decryption Profile and are tied directly to the Decryption Policy Rule.
The overall configuration flow on the Palo Alto firewall for Forward Proxy is: 1. Generate or import your Root CA certificate. 2. Create a Decryption Profile with your desired security settings. 3. Create a Decryption Policy Rule, specifying the source and destination zones, users, URL categories, and the action to decrypt or not decrypt. 4. Apply the Decryption Profile to the rule. 5. Commit the configuration. If you omit the profile, the firewall cannot decrypt even if the action is 'decrypt'. This is another classic exam trap.
Gather Requirements and Legal Approval
Before any configuration, identify which traffic must be decrypted and which must be excluded for legal or compliance reasons (e.g., banking, healthcare). Get written approval from legal and HR. This step is essential because the exam tests your awareness of compliance.
Deploy the Internal Root CA Certificate to Clients
Use a central management tool like MDM (Microsoft Intune, Jamf) or Group Policy to install the organisation's root CA certificate into the Trusted Root Certification Authorities store on every managed computer. Without this, the firewall's dynamic certificates will not be trusted by browsers.
Import the CA Certificate and Private Key onto the Firewall
On the Palo Alto Networks firewall, navigate to Device > Certificate Management. Import the same root CA certificate and its private key that you used to create the certificate for clients. The firewall needs the private key to dynamically sign certificates for the websites it is decrypting.
Create a Decryption Profile
In the firewall GUI, go to Objects > Decryption Profile. Create a new profile (e.g., 'Strict-Profile'). Configure security settings such as 'Block sessions with expired certificates', 'Block sessions with untrusted issuers', and optionally 'Strip ALPN'. This profile defines how the firewall handles the security of the decrypted connections.
Configure Decryption Policy Rules in the Correct Order
Go to Policies > Decryption. Add rules from top to bottom: first, a 'No Decrypt' rule for sensitive categories; second, a 'Decrypt' rule for trusted categories, applying the Decryption Profile; third, a catch-all 'No Decrypt' rule. Commit the configuration. This order ensures that sensitive traffic is never decrypted and that all other traffic is inspected.
Test and Monitor Decryption
Test from a client computer by accessing both decrypted and non-decrypted sites. Check the firewall's Traffic log and Decryption log to verify correct action. Monitor CPU usage on the firewall. Adjust rules as needed based on user feedback and performance data.
Let's imagine you are the new network security administrator for a mid-sized company called 'GlobalTech'. GlobalTech has 500 employees who all use company laptops to work. The CEO has heard that malware can hide in encrypted traffic and wants to ensure the company is protected. Your task is to implement SSL Forward Proxy decryption using a Palo Alto Networks firewall.
Step one: Planning and Gaining Approval. Before touching the firewall, you need to meet with the legal and HR departments. You explain that you must decrypt traffic to inspect it for threats, but you also must protect sensitive traffic. You agree to create a 'No Decrypt' rule for any traffic to banking sites, healthcare portals, and government websites. You also agree to exclude traffic from the CEO's laptop and the HR department for privacy reasons. This is an important real-world step the exam assumes you know.
Step two: Certificate Management. You need to deploy the organisation's root CA certificate to all 500 laptops. You cannot do this manually. Using your company's Mobile Device Management (MDM) system (like Microsoft Intune or Jamf), you push the certificate to every managed laptop. You also install this same certificate on the Palo Alto firewall. On the firewall, you go to Device > Certificate Management. You import the CA certificate and its private key. You also create a Decryption Profile called 'Strict-Security-Profile' where you check the box for 'Block sessions with expired certificates' and 'Block sessions with untrusted issuers'. You leave 'Strip ALPN' unchecked for now, as you want to test first.
Step three: Configuring the Policy. On the firewall's Policies > Decryption tab, you configure three rules in this exact order:
Rule 1: 'No-Decrypt-Sensitive'. Action: 'No Decrypt'. Source Zone: 'Trust'. Destination Zone: 'Untrust'. Category: 'Financial Services', 'Health and Medicine', 'Government'. Users: 'any'. This ensures bank logins are never decrypted.
Rule 2: 'Decrypt-All-Other'. Action: 'Decrypt'. Source Zone: 'Trust'. Destination Zone: 'Untrust'. Category: 'any'. Users: any. You apply the 'Strict-Security-Profile' to this rule. This decrypts all other outbound web traffic.
Rule 3: 'Fail-Close'. A final rule that blocks all traffic to unknown categories (e.g., newly registered domains) by setting the action to 'No Decrypt' *and* applying a Security Profile group that blocks unknown URLs. This prevents a bypass.
Step four: Testing and Monitoring. You test from your own laptop. You visit a known malware test site (with permission from your manager). You check the firewall's Traffic logs and Decryption logs. You can see the decrypted URL. You also test a banking site and confirm the Traffic log shows the category 'Financial Services' and the Decryption log shows 'no-decrypt'. This confirms your rules are working. You also monitor the firewall's CPU usage. Decryption is computationally expensive; if your firewall is struggling, you might need to upgrade hardware or refine your rules to decrypt less traffic.
Step five: Troubleshooting. A week later, a user in Sales complains that they cannot access a partner's site. The error they see is 'connection insecure' or 'ERR_CERT_AUTHORITY_INVALID'. You check the firewall logs. The session was decrypted, but the partner's website uses a self-signed certificate. Your 'Strict-Security-Profile' blocked it because the issuer was untrusted. The user needs access. You cannot lower security for everyone. Your solution is to create a specific exception: you add a new Decryption Policy Rule above the 'Decrypt-All-Other' rule for that specific destination URL with an Action of 'No Decrypt'. This is a common daily task for a network security engineer.
The PCNSE exam tests your understanding of decryption through a series of scenario-based multiple-choice questions. You will not be asked to execute CLI commands, but you must understand the logical flow and the policy hierarchy. The exam focuses on the 'why' and the 'sequence' more than the exact GUI path.
Key exam topics and what they actually test:
Order of Decryption Policy Rules: This is the most common trap. The exam will give you a scenario with multiple decryption rules and ask which one takes effect for a specific user visiting a specific site. The correct answer always depends on the 'first match' from top to bottom. They will try to trick you by listing rules alphabetically or by ID. Remember: Policy order in the list is the only thing that matters.
Decryption Profile vs. Decryption Policy: Beginners confuse these. The exam will describe a problem (like 'a user cannot access a site because of an untrusted certificate') and ask: 'What should you configure?' The correct answer is usually to modify the Decryption Profile, not the Decryption Policy. The policy determines *what* traffic to decrypt; the profile determines *how* to handle the security aspects of the decrypted connection.
Certificate Management: The exam tests which certificate needs to be distributed to the user's browser for a Forward Proxy to work without errors. The answer is the organisation's internal Root CA certificate. The exam also tests what happens if this certificate is not deployed: users will get certificate errors. They may also ask which certificate the firewall uses to sign the dynamically generated certificates (the answer: the internal CA certificate).
'No Decrypt' Rules: The exam will present a scenario where certain traffic must not be decrypted due to legal reasons (e.g., banking, healthcare). The correct answer is to create 'No Decrypt' rules and place them at the top of the list. A trap is to suggest using a Security Profile rule instead of a Decryption rule.
Supported Protocols: The exam tests that a Decryption Policy rule applies to SSL/TLS. It does not apply to SSH or other non-SSL encrypted traffic. A question may imply a problem with SSH and ask about decryption; the correct answer is that decryption does not apply to SSH, so the solution lies elsewhere (e.g., configuring an SSH proxy or a different feature).
Symmetric vs. Asymmetric Decryption: Palo Alto firewalls primarily use asymmetric decryption for Forward Proxy (the firewall holds a public/private key pair). However, the exam may touch on symmetric key regression, where the firewall negotiates a symmetric key with the server. Expect a question about which key the firewall uses to decrypt.
Traffic Flow: A classic question: 'After decrypting, does the firewall send the decrypted traffic to the destination?' The correct answer is no. The firewall inspects the decrypted content, then re-encrypts it using the original connection's parameters and forwards the re-encrypted traffic to the server. The server never sees decrypted traffic.
Blocking based on Certificate Characteristics: The exam tests the settings inside the Decryption Profile, specifically 'Block sessions with expired certificates' and 'Block untrusted issuer'. A question might present a scenario where a user cannot access a site because its certificate is self-signed. The answer: configure the Decryption Profile to block untrusted issuers, or create an exception by adding a 'No Decrypt' rule.
The exam will also include at least one question about the difference between Forward Proxy (outbound) and Inbound Inspection (inbound). They will present a scenario involving a public-facing web server and ask which type of decryption to use. The answer: Inbound Inspection, because the traffic is inbound to the server, not outbound from a user.
SSL/TLS Forward Proxy decryption uses a man-in-the-middle architecture where the firewall creates two separate encrypted connections to inspect the traffic in plain text.
A Decryption Policy rule must be paired with a Decryption Profile; the rule defines which traffic to match, and the profile defines the cryptographic security checks.
Decryption Policy rules are evaluated in order from top to bottom; the first match determines the action (Decrypt or No Decrypt), making rule ordering critical.
Always place 'No Decrypt' rules for sensitive URL categories like Financial Services, Health and Medicine, and Government at the top of your decryption policy.
The organisation's root CA certificate must be deployed to every managed client computer to prevent browser security warnings during decryption.
Decryption is computationally intensive; monitoring the firewall's CPU usage is essential, and selectively limiting decryption to necessary traffic can prevent performance degradation.
These come up on the exam all the time. Here's how to tell them apart.
Forward Proxy Decryption
Used for outbound traffic from internal users to the internet
Requires a root CA certificate deployed to all client computers
The firewall acts as a man-in-the-middle between client and external server
Inbound Inspection Decryption
Used for inbound traffic to an organisation's own public-facing server
Requires the server's own private key and certificate to be imported onto the firewall
The firewall decrypts incoming traffic to inspect it before forwarding it to the internal server
Decryption Policy Rule
Defines which traffic to decrypt or not decrypt based on source, destination, user, and URL category
Does not itself perform threat inspection; it only enables/disables decryption
Requires a matching Decryption Profile for the 'Decrypt' action to work
Security Policy Rule
Defines which traffic to permit, deny, or apply threat prevention to
Can include Security Profiles (Antivirus, Anti-Spyware, Vulnerability Protection) for inspection
Can function independently without any decryption; it inspects the outer packet headers
Decrypt Action in Decryption Policy
Tells the firewall to perform a man-in-the-middle and inspect the payload
Must be paired with a Decryption Profile that defines security checks
Is typically used for general web traffic (e.g., social media, email, search engines)
No Decrypt Action in Decryption Policy
Tells the firewall to forward the traffic without any decryption or inspection of the encrypted payload
Does not require a Decryption Profile
Is used for sensitive categories like financial services, healthcare, and government
Mistake
SSL decryption on a firewall makes the traffic visible in plain text to the end user's computer.
Correct
SSL decryption happens transparently on the firewall. The user's browser still sees an encrypted connection to the destination website. The decryption and re-encryption happen entirely within the firewall.
This mistake is common because people think of 'decrypt' as a one-way action. They imagine the firewall somehow shows the user the decrypted data, which would make HTTPS pointless for the user.
Mistake
If I create a Decryption Policy with the action 'Decrypt', the firewall will automatically decrypt all traffic matching that rule without any additional configuration.
Correct
A Decryption Policy rule with the 'Decrypt' action must also have a Decryption Profile attached to it. The profile contains the cryptographic settings and certificate checks. Without a profile, the firewall cannot perform the decryption.
This confusion comes from the GUI showing the 'Decrypt' action as a selectable option. Beginners assume selecting it is sufficient, not realising that the profile is a mandatory dependency.
Mistake
The firewall decrypts traffic by simply reading the encryption key from the connection.
Correct
The firewall does not 'read' the key. It performs a man-in-the-middle (MITM) operation: it creates two separate encrypted connections (one with the client, one with the server) and re-encrypts after inspecting the plaintext payload.
The technical term 'decryption' sounds passive, like opening a lock. People without cryptographic background imagine the firewall magically seeing the key. The concept of MITM, where the firewall actively inserts itself into the handshake, is more complex and not intuitive.
Mistake
Decryption is always necessary for all outbound HTTPS traffic to ensure security.
Correct
Decryption is a powerful tool, but it should be used selectively. Decrypting traffic to sensitive sites (banking, healthcare) can break compliance rules (like PCI DSS or HIPAA) and may be illegal in some jurisdictions. Best practise is to use 'No Decrypt' rules for these categories.
Security professionals naturally want maximum visibility. A new learner might think 'more decryption = more security'. They do not immediately consider the legal and compliance implications, which are critical for the exam.
Mistake
If I deploy the root CA certificate to the firewall, the firewall can decrypt all traffic without any further action on the client computers.
Correct
The root CA certificate must be deployed to *both* the firewall *and* all client computers that will have their traffic decrypted. If only the firewall has it, the client computers will display certificate errors because they do not trust the firewall's dynamically generated certificate.
Beginners view the firewall as the central device and think installing a certificate there is enough. They forget that the certificate's trust anchor is on the client machine. The browser on the client machine must trust the CA that signed the firewall's certificate, which means the client has to trust the root CA that issued it.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, SSL decryption adds latency because the firewall must perform cryptographic operations on every packet. However, for most general web browsing, the delay is barely noticeable (milliseconds). For high-throughput applications, you may need to use a dedicated decryption hardware module or limit decryption to only high-risk traffic categories.
The user will see a certificate error in their browser (e.g., 'Your connection is not private' or 'NET::ERR_CERT_AUTHORITY_INVALID') because the browser does not trust the certificate the firewall generated. They will be unable to access the website unless they manually bypass the warning, which is not a security best practise.
You can technically configure the firewall to do so, but it is strongly discouraged and often illegal. Decrypting financial traffic may violate the bank's terms of service and regulations like PCI DSS. It also exposes sensitive financial data to the organisation. The best practise is to create a 'No Decrypt' rule for the 'Financial Services' URL category.
A Decryption Policy rule is like a traffic filter that decides *which* traffic to decrypt (based on source, destination, user, category). A Decryption Profile is a set of security settings that tells the firewall *how* to handle the decryption (e.g., block expired certs, strip ALPN). You must attach a profile to a 'Decrypt' action rule for it to work.
No. SSL/TLS decryption is specifically for HTTPS and other SSL/TLS-based protocols. SSH uses a different encryption protocol and is not decrypted by this feature. To inspect SSH, you would need a different approach, such as an SSH proxy or a host-based security agent.
The firewall evaluates Decryption Policy rules sequentially from top to bottom. The first rule that matches the traffic is applied, and no further rules are considered. If you place a broad 'Decrypt' rule above a specific 'No Decrypt' rule for banking, the banking traffic will be decrypted unexpectedly, which could break compliance.
You've finished Decryption: SSL/TLS Policy Configuration and Forward Proxy. Continue through the PCNSE study guide to build a complete picture of the exam.
Done with this chapter?