Decryption Administration

[Link]
Contact Information
Corporate Headquarters:
Palo Alto Networks
3000 Tannery Way
Santa Clara, CA 95054
[Link]/company/contact-support

About the Documentation

• For the most recent version of this guide or for access to related documentation, visit the Technical
Documentation portal [Link].
• To search for a specific topic, go to our search page [Link]/[Link].
• Have feedback or questions for us? Leave a comment on any page in the portal, or write to us at
documentation@[Link].

Copyright
Palo Alto Networks, Inc.
[Link]

© 2024-2025 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo
Alto Networks. A list of our trademarks can be found at [Link]/company/
[Link]. All other marks mentioned herein may be trademarks of their respective companies.

Last Revised
August 28, 2025

Decryption Administration 2 ©2026 Palo Alto Networks, Inc.

Table of Contents
Decryption Basics...............................................................................................5
Decryption Policy Rules............................................................................................................. 7
Components of a Decryption Policy Rule..................................................................7
Decryption Policy Rule Considerations...................................................................... 9
Keys and Certificates for Decryption Policies................................................................... 11
SSL Decryption and Subject Alternative Names (SANs)...................................... 13
Perfect Forward Secrecy Support for SSL Decryption......................................... 14
Decryption Profiles................................................................................................................... 16
Decryption Profile Settings......................................................................................... 16
Decryption Profile: SSL Decryption.......................................................................... 23
Decryption Profile: No Decryption........................................................................... 27
Decryption Profile: SSH Proxy................................................................................... 28
SSL Forward Proxy................................................................................................................... 30
SSL Inbound Inspection........................................................................................................... 32
SSH Proxy................................................................................................................................... 34
TLS 1.3 Decryption...................................................................................................................37

Plan Your Decryption Deployment............................................................. 39

Develop a Decryption Strategy............................................................................................. 41
Plan a Public Key Infrastructure (PKI) Rollout................................................................... 43
Size Next-Generation Firewalls for Decryption Requirements...................................... 45
Deploy Decryption in Stages................................................................................................. 47

Enable Decryption........................................................................................... 49
Get Started with SSL Decryption..........................................................................................51
Define Traffic to Decrypt........................................................................................................53
Best Practices and Considerations for Decryption Policy Rules........................ 53
Apply Granular Settings to Traffic Matching a Decryption Policy Rule....................... 61
Best Practices and Considerations for Decryption Profiles.................................62
Fetch Certificates from Authority Information Access (AIA) URL.................................69
Configure SSL Forward Proxy................................................................................................72
Configure SSL Inbound Inspection........................................................................................85
Configure SSH Proxy................................................................................................................92
Test Decryption......................................................................................................................... 94

Decryption Exclusions..................................................................................101
Local SSL Decryption Exclusion Cache............................................................................. 103
Palo Alto Networks Predefined Decryption Exclusions................................................ 106
Exclude a Server from Decryption for Technical Reasons............................................109

Decryption Administration 3 ©2026 Palo Alto Networks, Inc.

Table of Contents

Exclude Traffic from Decryption for Business, Legal, or Regulatory Reasons..........112

Enable Users to Opt Out of SSL Decryption...................................................................117
Temporarily Disable TLS Decryption................................................................................. 119

PQC and Decryption.................................................................................... 121

Post-Quantum Cryptography Detection and Control....................................................122

Monitor Decryption...................................................................................... 125

Decryption Logs and Other Monitoring Tools................................................................ 127
Decryption Logs...........................................................................................................127
Decryption Reports.....................................................................................................131
Local Decryption Exclusion Cache..........................................................................132
Decryption Application Command Center (ACC) Widgets................................132
Decryption Port Mirroring........................................................................................ 136
Configure Decryption Logging............................................................................................ 138
Decryption Log Errors and Error Indexes.........................................................................143
Certificate Errors......................................................................................................... 144
Cipher Errors................................................................................................................ 146
Feature Errors.............................................................................................................. 147
HSM Errors................................................................................................................... 148
Protocol Errors............................................................................................................. 150
Resource Errors............................................................................................................151
Resume Errors.............................................................................................................. 152
Version Errors...............................................................................................................152
Root Status “Uninspected”........................................................................................154
Create Decryption Reports.................................................................................................. 155
Configure Decryption Port Mirroring................................................................................ 158

Troubleshoot Decryption............................................................................ 163

Investigate Reasons for Decryption Failure..................................................................... 165
Identify Weak Protocols and Cipher Suites..................................................................... 169
Troubleshoot Version Errors................................................................................................182
Troubleshoot Unsupported Cipher Suites........................................................................ 187
Identify Untrusted CA Certificates.....................................................................................190
Repair Incomplete Certificate Chains................................................................................ 192
Troubleshoot Pinned Certificates....................................................................................... 199
Troubleshoot Expired Certificates...................................................................................... 201
Troubleshoot Revoked Certificates....................................................................................204

Decryption Administration 4 ©2026 Palo Alto Networks, Inc.

Decryption Basics
Where Can I Use This? What Do I Need?

• No requirements.
•

The Transport Layer Security (TLS) protocol, which evolved from the Secure Sockets Layer (SSL), and
the Secure Shell (SSH) protocol secure communication between two entities, such as a web server
and a client. While SSL/TLS typically secures web-based communications, SSH typically secures
remote access to servers and devices. These protocols use public and private key cryptography to
establish secure connections. They encrypt data in a way that renders it meaningless to any entity
lacking the certificate and keys required to establish trust and decode the data. However, the
privacy and integrity that encryption provides can be exploited. For example, suppose an attacker
installs malware on an HTTPS website, and employees visit the site and unknowingly download
malware. The malware can use the infected employee endpoint to move laterally through the
network and compromise other systems. Thus, traffic should not be trusted automatically.
Decryption is the process of converting encrypted data into its original format, so that it's
readable. This process allows for inspection and visibility into SSL/TLS and SSH traffic. You can
decrypt both outbound and inbound traffic. SSL Forward Proxy inspects traffic exiting your
internal network to the internet. SSL Inbound Inspection inspects traffic entering internal network
servers. SSH Proxy inspects and controls traffic in SSH tunnels. Consider that you can’t block
traffic that you don't inspect.

SSH Proxy isn’t supported by Strata Cloud Manager.

Decrypt SSL and SSH traffic to:

• Prevent malicious, encrypted traffic from entering your network.
• Prevent sensitive information from exiting your network.
• Ensure the appropriate applications are running on a secure network.
• Identify noncompliance with legal, corporate, and other policies.
SSL decryption uses keys and certificates to establish a Next-Generation Firewall (NGFW) as a
trusted third party between a client and a server. The NGFW decrypts SSL/TLS traffic to plaintext
for inspection. Then, the NGFW re-encrypts the traffic before forwarding it to its destination,
ensuring the privacy and security of the data. SSL decryption works with Advanced Threat
Prevention, Advanced URL Filtering, and other services that require packet inspection. Without
SSL decryption, you couldn't create exceptions to URL categories for websites encrypted with
HTTPS. It also provides additional use cases for these services. For example, you can selectively
decrypt traffic based on URL categories and apply threat prevention controls.
SSH decryption does not require certificates. With SSH decryption enabled, an NGFW decrypts
and blocks or restricts SSH traffic according to your decryption policy rules and profiles. It
specifically tackles SSH tunneling. The NGFW also re-encrypts the SSH traffic as it exits. You

5
Decryption Basics

can use Decryption Port Mirroring to forward decrypted traffic to a third-party solution for
additional analysis and archiving. All mirrored traffic, including sensitive information, is forwarded
in cleartext.

Be aware of local laws and regulations about what traffic you can mirror and where and
how you can store the traffic. The use of SSL traffic is regulated in some countries and
jurisdictions.

Palo Alto Networks decryption is policy-based. NGFWs handle encrypted traffic according to
a decryption policy. A decryption policy consists of one or more decryption policy rules, which
specify the traffic targeted for decrypted, the type of decryption performed, and how certain
traffic is handled. Configure and associate a decryption profile with a decryption policy rule
to define the protocol versions and cipher suites supported by the client (in the case of SSL
decryption) or to configure certificate verification and other checks. For example, you can create a
no-decryption policy rule and profile to bypass decryption of financial or healthcare data.
Decrypting all traffic indiscriminately can be resource-intensive. When planning for and
implementing decryption, balance the need for thorough inspection with considerations of
performance, compliance, security, and resource management. For example, if performance and
sizing are major considerations, you might prioritize the decryption of traffic to high- or medium-
risk URL categories, traffic destined for critical servers, or business-critical traffic. Some traffic
can't be decrypted for technical, legal, or other reasons. Understand the traffic you can and can’t
decrypt when developing a decryption strategy. Use the Decryption Best Practices Checklist to
plan, implement, and maintain your decryption deployment.

Decryption Support
• NGFWs support Perfect Forward Secrecy (PFS). The Diffie-Hellman (DHE) and Elliptic Curve
Diffie-Hellman Ephemeral (ECDHE) key exchange algorithms are enabled in decryption profiles
by default.
• You can store and generate keys using an hardware security module (HSM) integrated with
a NGFW or Panorama. HSMs provide enhanced security for the private keys used in SSL
Forward Proxy and SSL Inbound Inspection decryption.
• SSL Forward Proxy and SSL Inbound Inspection support SSL session resumption because the
NGFW functions as a proxy in both modes.
• High availability (HA) isn’t supported for decrypted sessions. After a failover, a NGFW doesn't
support HA sync for decrypted SSL sessions. NGFWs also don’t resume decrypted SSL
Forward Proxy, SSL Inbound Inspection, or SSH Proxy sessions. The NGFW decrypts new
sessions that start after the failover based on your decryption policy.

Decryption Administration 6 ©2026 Palo Alto Networks, Inc.

Decryption Basics

Decryption Policy Rules

Where Can I Use This? What Do I Need?

• No requirements.
•

Decryption policy rules define how Next-Generation Firewalls (NGFW) and Prisma Access handle
encrypted traffic. These rules specify criteria for traffic that is or isn't decrypted and the type
of decryption performed on this traffic. One or more decryption policy rules form a decryption
policy. You can specify decryption criteria using network and policy objects. For example, you
can decrypt traffic from specific users, URL categories, or specific sources or destinations. The
types of traffic subject to decryption or the enforcement of decryption policy rules include SSL/
TLS traffic (including SSL-encapsulated protocols like IMAP(S), POP3(S), SMTP(S), and FTP(S)) and
SSH traffic, whether incoming or outgoing from your network. NGFW and Prisma Access support
three types of decryption: SSL Forward Proxy, SSL Inbound Inspection, and SSH Proxy.

SSH Proxy is not supported by Strata Cloud Manager.

The settings in a decryption policy rule allow for precise application of rules to different users,
groups, segments. For example, you can decrypt traffic to certain URL categories involving certain
zones when a certain user is requesting resources. In summary, creating decryption policy rules
that match traffic based on these criteria allows you to implement highly effective and efficient
security measures.

Components of a Decryption Policy Rule

Decryption policy rules enable you to specify the traffic you want to decrypt based on destination,
source, service, or URL category. You also define how you want to decrypt that traffic, by applying
a decryption profile with additional settings, for example, and log settings. Each setting type
corresponds to a different area of the interface, which may have slightly different names
depending on your management platform:
• Source
• Destination
• Service/URL Category (or Services and URLs)
• Options (or Action and Advanced Inspection)
• Log Settings
By specifying traffic based on IP addresses, ports, and protocols, and other characteristics you can
optimize the use of decryption resources, providing an additional layer of protection where it's
most needed.

Decryption Administration 7 ©2026 Palo Alto Networks, Inc.

Decryption Basics

General
In this section, enter basic information about the decryption policy rule, including the Name and
Description (helpful for differentiating between rules or various users). You can also add Tags,
and depending on your management platform, group rules by tags, add audit comments, and view
audit comments.

Source
Enforce traffic based on its origin. In this section, specify the source zone or source address that
defines the incoming source traffic to which the decryption policy rule will apply. Select or Add a
Zone, Addresses–Source Address, Address Groups, External Dynamic Lists, Regions, Users–User
Groups and Users, or Devices, including HIP Profiles and Device Profiles. For more information on
zones, see Segment Your Network Using Interfaces and Zones.

Destination
Enforce traffic based on where it terminates. In this section, specify the destination zone or
destination address of the traffic to which the rule will apply. You can add Zones and Addresses–
Source Address, Address Groups, External Dynamic Lists, Regions, and SaaS Application
Endpoints.

Service/URL Category (Services and URLs)

Apply a rule based on service (port and protocols) and URL categories. In this section, define
Service Entities–Services and Service Groups and URL Category Entities–URL Categories,
External Dynamic Lists, and SaaS Application Endpoints. You can exclude a certain website or
category of websites or applications from decryption using a predefined or custom URL category.
Services correspond to the TCP and UDP port numbers used by the service.

Options (Action and Advanced Inspection)

Choose whether to decrypt the traffic that matches a decryption policy rule and specify the type
of decryption you want to enable. In this section, specify the type of decryption the rule performs
(Action or Type). For traffic you choose not to decrypt, you can Enforce TLS and Certificate
Validation. You can also configure decryption log settings (if not Strata Cloud Manager), described
more in Log Settings, and use a decryption profile to block and control certain aspects of the
traffic matching the rule it's applied to. For example, you can use a decryption profile to perform
checks and verification on sessions, certificates, and protocol versions.

Log Settings

In NGFW deployments not managed by Strata Cloud Manager, this information is

configured in the Options section of the configuration.

In this section, enable the logging of successful or unsuccessful handshakes and configure
External Log Forwarding. Decryption logs save locally if an external forwarding option isn't
selected. You must also have a license for the forwarding service. For more information about
decryption logging, see Configure Decryption Logging.

Decryption Administration 8 ©2026 Palo Alto Networks, Inc.

Decryption Basics

Decryption Policy Rule Considerations

A well-designed decryption policy balances security concerns and other requirements and
intentionally decrypts, blocks, or allows different traffic. Remember, you can't block traffic that
you don't inspect, but you want to avoid unnecessarily blocking legitimate traffic. The traffic you
choose to decrypt is as important as the traffic you choose not to decrypt.
Consider the following before, during, and after you've created decryption policy rules:
• Regulatory compliance requirements
• Privacy concerns
• Performance impact
• Specific security needs
A Zero Trust perspective advocates for inspecting all traffic for malware and other threats.
Various controls are available to implement this approach effectively while respecting the above
requirements.
Before creating a decryption policy rule, develop a decryption strategy that:
• Identifies and prioritizes traffic to decrypt. This helps you to address resource consumption
concerns and decryption efficiency. For example, you can prioritize decrypting traffic to and
from specific users or groups.
• Identifies traffic that you don't want to decrypt for business, legal, or privacy reasons, such as
that of business executives.
• Recognizes traffic that can't be decrypted due to technical limitations such as a pinned
certificate.
Use the Planning a Decryption Deployment chapter and the Decryption Best Practices guide as
resources when making decisions about what you decrypt and how to approach decryption.

• Decrypt as much nonprivate and nonsensitive traffic as your NGFW and Prisma
Access resources permit. This reduces the attack surface by exposing and preventing
encrypted threats.
• Involve legal, finance, HR, executives, security, IT, and other stakeholders in the
development of your decryption deployment strategy.

Make Policy Rules As Specific and General As Needed and Order Them Appropriately. Many
Palo Alto Networks services rely on decryption. It's important to make sure that decryption policy
rules are as specific or general as needed and ordered appropriately.
• Decryption policy rules are evaluated from top to bottom. Place specific rules before more
general rules.
• Place rules that exclude traffic from decryption at the top. Decryption policy rules are
compared against the traffic in sequence.
Exclude Certain Traffic from Decryption.
• Create no-decrypt decryption policy rules for traffic that you choose not to decrypt because of
business, legal, regulatory, personal, or other reasons, such as financial-services, health-and-
medicine, or government traffic.

Decryption Administration 9 ©2026 Palo Alto Networks, Inc.

Decryption Basics

• For traffic that breaks decryption for technical reasons, such as certificate pinning add the
server to the SSL Decryption Exclusion list.
For granular control over how the traffic is decrypted, create and apply decryption profilesto
decryption policy rules.

Decryption Administration 10 ©2026 Palo Alto Networks, Inc.

Decryption Basics

Keys and Certificates for Decryption Policies

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Keys are strings of numbers typically generated using a mathematical operation involving random
numbers and large primes. Keys transform strings, such as passwords and shared secrets, from
unencrypted plaintext to encrypted ciphertext and from encrypted ciphertext to unencrypted
plaintext. Keys can be symmetric (the same key is used to encrypt and decrypt) or asymmetric
(one key is used for encryption and a mathematically related key is used for decryption). Any
system can generate a key.
X.509 certificates establish trust between a client and a server to establish an SSL connection. A
client attempting to authenticate a server (or a server authenticating a client) knows the structure
of the X.509 certificate and therefore knows how to extract identifying information about the
server from fields within the certificate, such as the FQDN or IP address (called a Common Name
or CN within the certificate) or the name of the organization, department, or user to which the
certificate was issued. A certificate authority (CA) must issue all certificates. After the CA verifies
a client or server, the CA issues the certificate and signs it with a private key.

If you have two CAs with the same subject and key, and one CA expires, delete (custom)
or disable (predefined) the expired CA. If you don't delete or disable an expired CA, the
Next-Generation Firewall (NGFW) can build a chain to the expired CA if it is enabled in the
trusted chain resulting in a Block page.

When you apply a decryption policy rule to traffic, a session between the client and the server is
established only if the NGFW trusts the CA that signed the server certificate. To establish trust,
the NGFW must have the server root CA certificate in its certificate trust list (CTL) and use the
public key in the root CA certificate to verify the signature. Next, the NGFW presents a copy of
the server certificate signed by the Forward Trust certificate to the client for authentication.
Alternatively, you can configure the NGFW to use an enterprise CA as a Forward Trust certificate
for SSL Forward Proxy. If the NGFW does not have the server root CA certificate in its CTL, it
presents a Forward Untrust copy of the server certificate to the client. The Forward Untrust
certificate ensures that clients receive a certificate warning when attempting to access sites
hosted by a server with untrusted certificates.
You can also use certificates when excluding servers from SSL decryption for technical reasons,
such as certificate pinning. SSL decryption requires keys and certificates to establish the NGFW
as a trusted third party and to establish trust between a client and a server to secure an SSL/TLS
connection. SSH decryption doesn't require certificates.
You can also verify the revocation status of certificates used for decryption.

Decryption Administration 11 ©2026 Palo Alto Networks, Inc.

Decryption Basics

Checking the revocation status of certificates used for SSL/TLS decryption adds time to
the process of establishing the session. The first attempt to access a site might fail if the
verification does not finish before the session times out. For these reasons, verification is
disabled by default.

For detailed information on certificates, see Certificate Management.

To control the trusted CAs that your NGFW trusts, use the Default Trusted Certificate
Authorities tab on your web interface.

The following table describes the different certificates used for decryption.

Certificates Used Description

With Decryption

Forward Trust (Used The certificate the NGFW presents to clients during decryption if the
for SSL Forward site the client attempting to connect to has a certificate signed by a
Proxy decryption) CA that the NGFW trusts. To configure the Forward Trust certificate
presented to clients when the server certificate is signed by a trusted
CA, see Configure SSL Forward Proxy.
By default, the NGFW determines the key size to use for the
client certificate based on the key size of the destination server.
However, you can configure the key size for SSL Forward Proxy
server certificates. For added security, consider storing the private key
associated with the Forward Trust certificate on a hardware security
module (HSM). (See Store Private Keys on an HSM.)

Back up the private key associated with the NGFW's

Forward Trust CA certificate (not the NGFW's master
key) in a secure repository so that if an issue occurs with
the NGFW, you can still access the Forward Trust CA
certificate. For added security, consider storing the private
key associated with the Forward Trust certificate on an
HSM. (See Store Private Keys on an HSM.)

Forward Untrust The certificate the NGFW presents to clients during decryption if
(Used for SSL the site the client is attempting to connect to has a certificate that is
Forward Proxy signed by a CA that the NGFW does not trust. To configure a Forward
decryption) Untrust certificate, see Configure SSL Forward Proxy.

SSL Inbound The certificates of the servers on your network for which you want
Inspection to perform SSL Inbound Inspection of traffic destined for those
servers. Import the server certificates onto the NGFW or management
platforms for NGFW or Prisma Access.

Decryption Administration 12 ©2026 Palo Alto Networks, Inc.

Decryption Basics

Certificates Used Description

With Decryption
Beginning in PAN-OS 8.0, NGFWs use the Elliptic Curve
Diffie-Hellman Ephemeral (ECDHE) algorithm to perform
strict certificate checking. This means that if the NGFW
uses an intermediate certificate, you must reimport the
certificate from your web server to the NGFW after you
upgrade to a PAN-OS 8.0 or later release and combine the
server certificate with the intermediate certificate (install
a chained certificate). Otherwise, SSL Inbound Inspection
sessions that have an intermediate certificate in the chain
fail. To install a chained certificate:
1. Open each certificate (.cer) file in a plain-text editor such
as Notepad.
2. Paste each certificate end-to-end with the Server
Certificate at the top with each signer included below.
3. Save the file as a text (.txt) or certificate (.cer) file. The
name of the file cannot contain blank spaces.
4. Import the combined (chained) certificate.

SSL Decryption and Subject Alternative Names (SANs)

Some browsers require server certificates to use a Subject Alternative Name (SAN) to specify the
domains the certificate protects. These browsers no longer support certificate matching based
on a server certificate's Common Name (CN). SANs enable a single server certificate to protect
multiple hostnames or domains, while CNs are less well-defined than SANs and can protect only a
single domain or all first-level subdomains on a domain.
If a server certificate contains only a CN, browsers that require a SAN will not allow end users
to connect to the requested web resource. To address this, NGFWs can add a SAN to the
impersonation certificate they generate, establishing themselves as trusted third-parties during
SSL decryption. When a server certificate contains only a CN, the NGFW performing SSL
decryption copies the server certificate CN to the impersonation certificate SAN. The NGFW
presents the impersonation certificate with the SAN to the client, and the browser is able to
support the connection. End users can continue to access the resources they need, and the
NGFW can decrypt the sessions.
To enable SAN support for decrypted SSL traffic, update the decryption profile attached to the
relevant decryption policy rule:
• (PAN-OS & Panorama) Select Objects > Decryption > SSL Decryption > SSL Forward Proxy
and select Append certificate’s CN value to SAN extension.

Decryption Administration 13 ©2026 Palo Alto Networks, Inc.

Decryption Basics

• (Strata Cloud Manager)

1. Select Manage > Configuration > NGFW and Prisma Access > Security Services >
Decryption.
2. Select or create a decryption profile. Under the SSL Forward Proxy section of the SSL/TLS
Decryption settings, select Advanced. Then, under Server Certificate Verification, select
Append certificate's CN value to SAN extension.
3. Save the Advanced SSL Forward Proxy Settings, and then Save the profile.
4. Click Push Config to activate the settings.

SSL Decryption for Elliptical Curve Cryptography (ECC) Certificates

The NGFW automatically decrypts SSL traffic from websites and applications using Elliptic Curve
Cryptography (ECC) certificates, including Elliptic Curve Digital Signature Algorithm (ECDSA)
certificates. As organizations transition to using ECC certificates to benefit from the strong keys
and small certificate size, you can continue to maintain visibility into and safely enable ECC-
secured application and website traffic.

Decryption for websites and applications using ECC certificates is not supported for traffic
that is mirrored; encrypted traffic using ECC certificates must pass through a NGFW
directly for the NGFW to decrypt it.
You can use a hardware security module (HSM) to store the private keys associated with
ECDSA certificates.

Perfect Forward Secrecy Support for SSL Decryption

Perfect Forward Secrecy (PFS) is a secure communication protocol that prevents the compromise
of one encrypted session from leading to the compromise of multiple encrypted sessions. With
PFS, a server generates unique private keys for each secure session it establishes with a client. If
an attacker compromises a server's private key, they can only access the single session associated
with that key. An attacker cannot retrieve data from past and future sessions because the server
establishes each connection with a uniquely generated key.
You can decrypt SSL sessions established with Perfect Forward Secrecy, maintaining PFS
protection for past and future sessions. This includes SSL sessions with servers that present
Elliptic Curve Cryptography (ECC) certificates or Subject Alternative Name (SAN) certificates.
Decryption profiles support the Diffie-Hellman (DHE) and Elliptic Curve Diffie-Hellman (ECDHE)
key exchange algorithms by default. To enable PFS support for decryption, apply a decryption
profile with the DHE and ECDHE key exchange algorithms selected to an SSL Inbound Inspection
or SSL Forward Proxy decryption policy rule.

If you use the DHE or ECDHE key exchange algorithms to enable PFS support for SSL
decryption, you can use an hardware security module (HSM) to store the private keys for
SSL Inbound Inspection.

When you configure SSL Inbound Inspection and use a PFS cipher, session resumption is
not supported.

Decryption Administration 14 ©2026 Palo Alto Networks, Inc.

Decryption Basics

Decryption Administration 15 ©2026 Palo Alto Networks, Inc.

Decryption Basics

Decryption Profiles
Where Can I Use This? What Do I Need?

• No requirements.
•

Decryption profiles specify the checks and connection parameters that apply to traffic you
decrypt or exclude from decryption. These settings harden network security by preventing
risky connections, such as sessions with invalid certificates or weak protocols. After creating a
decryption profile, associate it with a decryption policy rule. Next-Generation Firewalls (NGFWs)
enforce the profile settings on traffic that matches the conditions of a decryption policy rule.
You can create decryption profiles for each type of decryption: SSL Forward Proxy, SSL Inbound
Inspection (Proxy), and SSH Proxy. You can also create a no-decryption profile for traffic you
choose not to decrypt—such as traffic containing personal or sensitive information or traffic
subject to local laws and regulations. This often includes traffic to the health-and-medicine and
financial-services categories. Each profile type has different checks to configure: certificate
verification checks, session mode checks, and failure checks. Decryption profiles for SSL
decryption additionally define TLS connection parameters.
You can also use the default decryption profile, which enforces basic, recommended protocol
versions and cipher suites for decrypted SSL/TLS traffic.

Don’t weaken the decryption profile you apply to most sites by accommodating less
secure sites. Instead, create one or more separate decryption profiles for sites that must
remain accessible but don’t support strong protocol versions or cipher suites.
You can also create separate decryption profiles for different types of URL categories to
fine-tune security versus performance for traffic that doesn't contain sensitive material.

• Apply a decryption profile to all decryption policy rules, including rules for traffic you
don't decrypt. No-decryption profiles block sessions with expired certificates and
untrusted issuers as an extra precaution.
• Enable the tighter decryption controls described in SSL Decryption, No Decryption,
and SSH Proxy.

Decryption Profile Settings

Settings vary by type of decryption profile. The Profile Settings and Profile Types Matrix shows
which checks apply to each type of decryption profile.
• Unsupported Mode Checks—These settings block sessions that use weak risky protocol
versions and cipher suites. If you don’t block sessions with unsupported modes, users see

Decryption Administration 16 ©2026 Palo Alto Networks, Inc.

Decryption Basics

warning messages when they connect to potentially unsafe servers. However, they can click
through the warning to access these sites.
• Block sessions with client authentication
This option blocks sessions that require client authentication unless the session involves a
site on the decryption exclusion list. The NGFW can’t decrypt sessions that require client
authentication because it needs both client and server certificates to perform bidirectional
decryption, and with client authentication, the NGFW only knows the server certificate.
Enable this option only if no critical applications require client authentication.
If you don’t block sessions requiring client authentication, the NGFW allows the session
when it attempts decryption and adds an entry containing the URL or IP address of the
server, the application, and corresponding decryption profile to its Local SSL Decryption
Exclusion Cache.
• Block sessions with unsupported cipher suites
This option blocks sessions if the NGFW doesn’t support the cipher suites a client presents
during the SSL/TLS handshake. To specify the key exchange algorithms, encryption
algorithms, and authentication algorithms the NGFW supports, edit the SSL Protocol
Settings in your decryption profiles.
• Block sessions with unsupported algorithms
This option blocks sessions if the client or server presents SSH algorithms PAN-OS doesn't
support. For a list of supported SSH algorithms, see PAN-OS Decryption Cipher Suites.
• Block sessions with unsupported versions
This option blocks sessions if the client or server presents SSL/TLS protocol versions the
NGFW doesn't support. To specify the minimum and maximum SSL/TLS protocol versions
allowed on your network, edit the SSL Protocol Settings in your decryption profiles.
• Failure Checks—These settings block sessions if system resources are insufficient to perform
decryption or a required component such as a hardware security module (HSM) with private
keys for decryption is not available, which prevents decryption.
• Block sessions if resources not available
When enabled, the NGFW drops traffic if it lacks the resources to decrypt the traffic. This
prevents encrypted traffic from entering your network uninspected and prevents leakage.
However, blocking sessions when resources aren’t available may make sites that users
normally can access temporarily unreachable.
Weigh your company’s security compliance stance and the importance of the user
experience against tighter security when deciding whether to enable this option.
Alternatively, consider using NGFW models with more processing power to decrypt
more traffic if resource limitations become problematic. Size Next-Generation Firewalls

Decryption Administration 17 ©2026 Palo Alto Networks, Inc.

Decryption Basics

for Decryption Requirements describes considerations to make when determining your

decryption and NGFW sizing needs.
• Block sessions if HSM not available
This option blocks sessions if a hardware security module (HSM) is not available to sign
certificates.
If you store private keys on an HSM, consider your compliance rules about where the
private key must come from and how to handle encrypted traffic when the HSM isn’t
available. If your company mandates the use of an HSM for private key signing, enable this
option. If your company is less strict about this, don't enable this option. Further, if the HSM
is critical to your business, run it in a high availability (HA) pair.

If the HSM is down, the NGFW can only decrypt sites for which it has cached the
HSM response.
• Block downgrade on no resource
This option prevents NGFWs from downgrading a TLSv1.3 connection to TLSv1.2 when an
NGFW has no available TLSv1.3 processing resources. Instead, when it exhausts its TLSv1.3
resources, the NGFW drops TLSv1.3 traffic. However, blocking downgrade when resources
aren’t available might make sites that users normally can access temporarily unreachable.
If you don’t enable this option, the NGFW downgrades connections to TLSv1.2 when it
exhausts TLSv1.3 resources.
Weigh your company’s security compliance stance and the importance of the user
experience against tighter security when deciding whether to enable this option. Consider
creating a separate decryption policy rule and profile to govern the decryption for sensitive
traffic for which you don’t want to downgrade the TLS version.
• Block sessions on SSH errors
This option blocks sessions when SSH errors occur.
• Server Certificate Verification—These settings block sessions with invalid, compromised, or
suspicious server certificates to ensure users communicate with legitimate servers and that

Decryption Administration 18 ©2026 Palo Alto Networks, Inc.

Decryption Basics

data is transmitted securely. For example, you can prevent executives whose traffic you don't
inspect from accessing websites with expired certificates.
• Block sessions with expired certificates
This option blocks sessions with servers that have expired certificates and prevents access
to potentially insecure sites. If you don't enable this option, users can connect with and
transact with potentially malicious sites despite warnings about their safety.
• Block sessions with untrusted issuers
This option blocks sessions with servers that have untrusted certificate issuers. Untrusted
issuers may indicate meddler-in-the-middle, replay, or other attacks.
• Block sessions with unknown certificate status
This option blocks SSL/TLS sessions when a server certificate has a revocation status of
unknown.

This setting may tighten security too much for general use as certificate status may
be unknown for multiple reasons. However, it may be appropriate for high-security
areas of the network like data centers.
• Block sessions on SNI mismatch with Server Certificate (SAN/CN)
This option automatically denies any sessions where the Server Name Indication (SNI)
doesn't match the Subject Alternative Name (SAN) or Common Name (CN) fields of a server
certificate. This prevents SNI spoofing and reduces the risk of visiting a malicious website.
Palo Alto Networks recommends enabling this option if you configure an explicit proxy or
transparent proxy. For more information, refer to Configure a Web Proxy in the PAN-OS
Networking Administrator's Guide.
• Block sessions on certificate status check timeout
This option blocks sessions when certificate revocation checks (CRL or OCSP) time out,
even if a certificate is valid. Revocation servers can be slow to respond, so this option

Decryption Administration 19 ©2026 Palo Alto Networks, Inc.

Decryption Basics

introduces a tradeoff between security and user experience. Consider your company’s
security compliance stance when deciding whether to enable this option.

• If you enable this option and timeouts occur frequently, you can increase the
Certificate Status Timeout (sec) value. This interval limits the time that an
NGFW waits for a response from either the CRL or OCSP service. In the following
figure, this value has been increased to 8 (the default is 5 seconds):

• Enable both verification methods for better coverage. Server certificates can
contain the CRL URL in the CRL Distribution Point (CDP) extension or the OCSP
URL in the Authority Information Access (AIA) certificate extension.
For a step-by-step procedure, see Verify Revocation Status of Certificates Used
for SSL/TLS Decryption.
• Restrict certificate extensions
This option limits the certificate extensions in the server certificate to key usage and
extended key usage and blocks certificates with other extensions. In certain deployments,
other certificate extensions may be necessary. Enable this option only if your deployment
doesn't require additional certificate extensions.
• Append certificate’s CN value to SAN extension
This option ensures users can access web resources on browsers that require SSL/TLS
certificates to include the Subject Alternative Name (SAN) extension and don't support
Common Name (CN) matching, when the certificate is missing the SAN extension. The
NGFW addresses this issue by adding the SAN extension (based on the CN) to the
impersonation certificate.
• Automatically Fetch Intermediate Certificates
This option enables the NGFW to download missing intermediate certificates from the URL
in the Authority Information Access (AIA) extension after a server presents an incomplete

Decryption Administration 20 ©2026 Palo Alto Networks, Inc.

Decryption Basics

certificate chain during the TLS handshake. The NGFW caches these certificates for up to 1
week and uses them to validate the server in future SSL Forward Proxy connections.
• Bypass Server Certificate Verification

Enabling this option disables all other Server Certificate Verification settings. To
minimize potential risks of bypassing certificate checks, apply decryption profiles
with this setting enabled only to decryption policy rules that control traffic to
trusted servers that are known to fail certificate validation.

This option enables the NGFW to ignore server certificate issues (for example, missing
intermediate certificates) and present a Forward Trust certificate to force decryption.
Because this option disables other certificate checks, you must acknowledge a warning
to enable it. To protect against unknown vulnerabilities, the NGFW does not save these
sessions to the session cache; thus, session resumption isn't supported.
The following table lists the checks you can enable for each decryption profile type.

Profile Types
Settings SSL Forward SSL Inbound SSH Proxy No
Proxy Inspection Decryption

Block Yes No No Yes

sessions
with expired
certificates

Block Yes No No Yes

sessions with
untrusted
issuers

Block Yes No No No
sessions with
unknown
Server
certificate
Certificate
status
Verification
Block Yes No No No
sessions on
SNI mismatch
with Server
Certificate
(SAN/CN)

Block Yes No No No
sessions on
certificate
status check
timeout

Decryption Administration 21 ©2026 Palo Alto Networks, Inc.

Decryption Basics

Profile Types
Settings SSL Forward SSL Inbound SSH Proxy No
Proxy Inspection Decryption

Restrict Yes No No No
certificate
extensions

Append Yes No No No
certificate’s
CN value
to SAN
extension

Automatically Yes No No No
Fetch
Intermediate
Certificates

Bypass Server Yes No No No

Certificate
Verification

Block Yes Yes Yes No

sessions with
unsupported
versions

Block Yes Yes Yes No

sessions with
unsupported
Unsupported cipher suites
Mode
Checks Block No No Yes No
sessions with
unsupported
algorithms

Block Yes No No No
sessions
with client
authentication

Block Yes Yes Yes No

sessions if
Failure resources not
Checks available

Block Yes Yes No No

sessions if

Decryption Administration 22 ©2026 Palo Alto Networks, Inc.

Decryption Basics

Profile Types
Settings SSL Forward SSL Inbound SSH Proxy No
Proxy Inspection Decryption
HSM not
available

Block Yes Yes No No

downgrade
on no
resource

Block No No Yes No
sessions on
SSH errors

Decryption Profile: SSL Decryption

The SSL Decryption tab manages settings for SSL Forward Proxy and SSL Inbound Inspection.
Both profile types include settings for various checks, such as unsupported mode checks, failure
checks, and client extensions. You can also specify the TLS versions, key exchange algorithms,
encryption algorithms, and authentication algorithms that a client, server, and NGFW (acting as
a proxy) can negotiate. Only the SSL Forward Proxy profile includes options for server certificate
verification.

You may need to allow traffic on your network from sites that use client authentication
and are not in the predefined sites on the SSL decryption exclusion list. Create a
decryption profile that allows sessions with client authentication. Add it to a decryption
policy rule that applies only to the servers that host the application. To further increase
security, you can require multi-factor authentication to complete the user login process.

The following sections summarize the profile settings and recommendations for SSL Forward
Proxy, SSL Inbound Inspection, and the SSL Protocol Settings. Select an option to learn more
about the unique settings and recommendations offered.
• SSL Forward Proxy
• SSL Inbound Inspection
• SSL Protocol Settings

SSL Forward Proxy

The SSL Forward Proxy decryption profile controls server verification, session mode checks, and
failure checks for outbound SSL and TLS traffic defined in the Forward Proxy decryption policy
rules to which you attach the profile.

SSL Forward Proxy can't decrypt some sessions, such as sessions with client
authentication or pinned certificates because the NGFW is a proxy device. Being a proxy
also means that the NGFW does not support high availability (HA) sync for decrypted SSL
sessions.

Decryption Administration 23 ©2026 Palo Alto Networks, Inc.

Decryption Basics

The following figure shows the general best practice recommendations for SSL Forward Proxy
decryption profiles, but the settings you use also depend on your company’s security compliance
rules and local laws and regulations. There are also specific best practices for perimeter internet
gateway decryption profiles and for data center decryption profiles.

SSL Inbound Inspection

The SSL Inbound Inspection decryption profile controls the session mode checks and failure
checks for inbound SSL/TLS traffic defined in the Inbound Inspection decryption policy
rules to which you attach the profile. The following figure shows the general best practice
recommendations for Inbound Inspection decryption profiles, but the settings you use also
depend on your company’s security compliance rules and local laws and regulations.

SSL Inbound Inspection can't decrypt some sessions, such as sessions with client
authentication or pinned certificates, because the NGFW is a proxy device. Being a proxy
also means that the NGFW does not support high availability (HA) sync for decrypted SSL
sessions.

Decryption Administration 24 ©2026 Palo Alto Networks, Inc.

Decryption Basics

SSL Protocol Settings

The SSL Protocol Settings tab controls the protocol versions and cipher suites supported for SSL
Forward Proxy and SSL Inbound Inspection. You can decide whether to allow vulnerable or weak
SSL/TLS protocol versions, encryption algorithms, and authentication algorithms. SSL Protocol
Settings apply to outbound SSL Forward Proxy traffic and inbound SSL Inbound Inspection traffic.
These settings don’t apply to SSH Proxy traffic or traffic that you don’t decrypt.
General Guidelines
Always use the strongest protocols and cipher suites possible. Weak protocols and ciphers have
known vulnerabilities that attackers can exploit. Avoid weakening the decryption profile you apply
to most sites for a few exceptions. Instead, create separate decryption profiles for applications
and websites that rely on outdated protocols or ciphers. For example, to support a business-
critical legacy site that uses a weak encryption algorithm, create a decryption profile with only
that algorithm enabled. Then, create a dedicated decryption policy rule that allows traffic to
the legacy site (specify the URL as the destination). Next, apply the decryption profile to the
decryption policy rule. Finally, place the decryption policy rule above your general decryption
policy rules. This approach allows you to support legacy applications without weakening your
overall security posture.
The following figure shows the general best practice recommendations for SSL Protocol Settings.
There are also specific best practices for perimeter internet gateway decryption profiles and for
data center decryption profiles.

When you configure SSL Protocol Settings for SSL Inbound Inspection traffic, create
separate profiles for servers with different security capabilities. For example, if one set of
servers supports only RSA, the SSL Protocol Settings only need to support RSA. However,
the SSL Protocol Settings for servers that support PFS should support PFS. Configure SSL
Protocol Settings for the highest level of security that the target server you're protecting
supports, but check performance to ensure that the NGFW and Prisma Access resources
can handle the higher processing load that higher security protocols and algorithms
require.

Decryption Administration 25 ©2026 Palo Alto Networks, Inc.

Decryption Basics

Protocol Versions
• Set Min Version to TLSv1.3 for the strongest security. Business sites that value security
support TLSv1.3. However, if a site or category of sites only supports weak or outdated
ciphers, evaluate whether the site hosts a legitimate business application. If yes, create a
decryption profile with a Min Version equal to the strongest cipher that the site supports.
Then, apply this profile to decryption policy rules that target only the specific site or sites in
question. If the site belongs to a category of sites that you don’t need for business purposes,
use URL filtering to block access to the entire category.

Qualys SSL Labs SSL Pulse web page provides current statistics on the percentages of
different ciphers and protocols in use on the 150,000 most popular sites in the world
so you can see trends and understand how widespread worldwide support is for more
secure ciphers and protocols.
• Set Max Version to Max rather than a specific version, so that as the protocols improve, the
NGFW or Prisma Access automatically supports the newest and best protocols. Whether you
intend to attach a decryption profile to a decryption policy rule that governs inbound (SSL
Inbound Inspection) or outbound (SSL Forward Proxy) traffic, avoid allowing weak algorithms.

If your decryption policy supports mobile applications, many of which use pinned
certificates, set the Max Version to TLSv1.2. Because TLSv1.3 encrypts certificate
information that wasn’t encrypted in previous TLS versions, the NGFW can’t
automatically add decryption exclusions based on certificate information, which
affects some mobile applications. Therefore, if you enable TLSv1.3, the NGFW may
drop some mobile application traffic unless you create a no-decryption policy rule for
that traffic.
If you know the mobile applications you use for business, consider creating a separate
decryption policy rule and profile for those applications so that you can enable TLSv1.3
for all other application traffic.
Key Exchange Algorithms
RSA, DHE, and ECDHE key exchange algorithms are enabled by default. Only DHE and ECDHE
support Perfect Forward Secrecy.

Only ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) is supported for TLSv1.3

connections.

To support HTTP/2 traffic, leave the ECDHE box checked.

(PAN-OS 12.1.2 and TLSv1.3 only) You can configure post-quantum cryptography (PQC)
key exchange algorithms in addition to RSA, DHE, and ECDHE. Select the Post-quantum
Cryptography (PQC) tab:
• Classical—Select RSA, DHE, and ECDHE. Leave all three boxes checked to support all classical
key exchange algorithms unless the minimum protocol version you support is TLSv1.3, which
only supports ECDHE.

Decryption Administration 26 ©2026 Palo Alto Networks, Inc.

Decryption Basics

• Post-quantum Cryptography (PQC)—Select PQC-Standard or PQC-Experimental:

• PQC-Standard enables key exchange algorithms that have been standardized by the
National Institute of Standards and Technology (NIST): ML-KEM
• PQC-Experimental enables the following nonstandardized PQC algorithms: HQC, Bike, and
Frodo-KEM
Preferred Session Settings—Select the proxy sessions that prioritize PQC:
The NGFW negotiates a PQ KEM for the selected sessions when possible. The NGFW
translates between PQC and classical encryption, so it can secure one proxy session with PQC
even if the other side only supports classical algorithms.

If a client or server doesn't support PQC, the NGFW attempts to negotiate an existing
cipher supported by these endpoints as a fallback mechanism.

• Post-Quantum SSL preferred for Client-side session—The NGFW (acting as a server)

negotiates PQC algorithms if included in client's cipher suite list
• Post-Quantum SSL preferred for Server-side session—The NGFW (acting as a client) places
PQC algorithms first in its cipher suite list
Encryption Algorithms
• If you set the minimum protocol version to TLSv1.2, the older, weaker 3DES and RC4
algorithms are automatically unchecked (blocked).
• If you set the minimum protocol version to TLSv1.3, the 3DES, RC4, AES128-CBC, and
AES256-CBC algorithms are automatically blocked.
• For any traffic for which you must allow a weaker TLS protocol, create a separate decryption
profile and apply it only to traffic for that site, and deselect the appropriate boxes to allow
the algorithm. Allowing traffic that uses the 3DES or RC4 algorithms exposes your network to
excessive risk. If blocking 3DES or RC4 prevents you from accessing a site that you must use
for business, create a separate decryption profile and decryption policy rule for that site.
Authentication Algorithms
The NGFW automatically blocks the older, weaker MD5 algorithm. When TLSv1.3 is the minimum
protocol version, the NGFW also blocks SHA1. Don’t allow MD5 authenticated traffic on your
network; SHA1 is the weakest authentication algorithm you should allow. If no necessary sites use
SHA1, block SHA1 traffic to further reduce the attack surface.

Decryption Profile: No Decryption

No-decryption profiles enable server certificate verification for traffic you choose not to decrypt
for legal, compliance, or other non-technical reasons. You can block sessions with expired
certificates or untrusted certificate issuers. Apply this profile only to decryption policy rules with
a Do Not Decrypt action (see Exclude Traffic from Decryption for Business, Legal, or Regulatory
Reasons.)

To exclude traffic that can't be decrypted for technical reasons (for example, certificate
pinning), add the hostnames of the websites or applications to the decryption exclusions
list.

Decryption Administration 27 ©2026 Palo Alto Networks, Inc.

Decryption Basics

The following figure shows the general best practice recommendations for no-decryption profiles.

Don’t attach a no-decryption profile to decryption policy rules for TLSv1.3 traffic that
you don’t decrypt. Unlike previous versions, TLSv1.3 encrypts certificate information, so
the NGFW has no visibility into certificate data and therefore can't block sessions with
expired certificates or untrusted issuers, so the profile has no effect. (The NGFW can
perform certificate checks with TLSv1.2 and earlier because those protocols don’t encrypt
certificate information and you should apply a no-decryption profile to their traffic.)
However, you should create a decryption policy rule for TLSv1.3 traffic that you don’t
decrypt because the NGFW does not log undecrypted traffic unless a decryption policy
rule controls that traffic.

(Applies to TLSv1.2 and earlier) If you choose to allow sessions with untrusted issuers
(not recommended) and only Block sessions with expired certificates, there is a scenario
in which a session with a trusted, expired issuer may be blocked inadvertently. When
the NGFW certificate store contains a valid, self-signed trusted CA and the server sends
an expired CA in the certificate chain, the NGFW does not check its certificate store.
Instead, it blocks the session based on the expired CA when it should find the trusted,
valid alternative trust anchor and allow the session based on that trusted self-signed
certificate.
To avoid this scenario, select Block sessions with untrusted issuers in addition to Block
sessions with expired certificates. This forces the NGFW to check its certificate store, find
the self-signed trusted CA, and allow the session.

Decryption Profile: SSH Proxy

The SSH Proxy decryption profile controls the session mode checks and failure checks for SSH
traffic defined in the SSH Proxy decryption policy rules to which you attach the profile. The
following figure shows the general best practice recommendations for SSH Proxy decryption
profiles, but the settings you use also depend on your company’s security compliance rules and
local laws and regulations.

Decryption Administration 28 ©2026 Palo Alto Networks, Inc.

Decryption Basics

NGFWs don’t perform content and threat inspection on SSH tunnels (port forwarding).
However, they distinguish between the SSH application and the SSH-tunnel application.
If the NGFW identifies SSH tunnels, it blocks the tunneled traffic and restricts the traffic
according to configured Security policy rules.

Decryption Administration 29 ©2026 Palo Alto Networks, Inc.

Decryption Basics

SSL Forward Proxy

Where Can I Use This? What Do I Need?

• No requirements.
•

You can configure SSL Forward Proxy to decrypt and inspect SSL/TLS traffic from internal users
to the internet. SSL Forward Proxy decryption prevents malware concealed as SSL encrypted
traffic from being introduced into your corporate network. When you enable SSL Forward Proxy,
an NGFW acts as a forward proxy. It creates two separate sessions: one between the client and
the NGFW, and the other between the NGFW and the server. The NGFW uses certificates to
transparently represent the client to the server and the server to the client, establishing itself as
a trusted third party or meddler in the middle. As a result, the client believes it's communicating
directly with the server, and the server believes it's communicating directly with the client. All
web traffic goes through the NGFW, which applies decryption profiles and Security policy rules
and profiles to the traffic.
(For details on certificates, see Keys and Certificates for Decryption Policies.)

Because the NGFW is a proxy device, it can’t decrypt certain sessions, such as those with
client authentication or pinned certificates. It also doesn't support high availability (HA)
sync for decrypted SSL sessions.

The following figure shows this process in detail.

Decryption Administration 30 ©2026 Palo Alto Networks, Inc.

Decryption Basics

1. The internal client on your network attempts to initiate a TLS session with an external server.
2. The NGFW intercepts the client’s SSL certificate request. For the client, the NGFW acts as the
external server, though the actual secure session is established with the NGFW.
3. The NGFW forwards the client’s SSL certificate request to the server to initiate a separate
session with the server. To the server, the NGFW looks like the client, the server doesn’t know
there’s a meddler in the middle, and the server verifies the certificate.
4. The server sends the NGFW a signed certificate intended for the client.
5. The NGFW analyzes the server certificate. If the server certificate is signed by a CA that the
NGFW trusts and meets the policy rules and profiles you configure, the NGFW generates an
SSL Forward Trust copy of the server certificate and sends it to the client.
If the server certificate is signed by a CA that the NGFW does not trust, the NGFW generates
an SSL Forward Untrust copy of the server certificate and sends it to the client. The certificate
copy contains extensions from the original server certificate and is called an impersonation
certificate because it is not the actual server certificate. If the NGFW does not trust the server,
the client displays a warning message that the site they’re attempting to connect to isn’t
trusted. Enable users to opt out of SSL decryption, so that the client can choose to proceed or
terminate the session.
6. The client verifies the NGFW’s impersonation certificate. The client then initiates a session
key exchange with the server, which the NGFW proxies in the same manner as it proxies the
certificates. The NGFW forwards the client key to the server and makes an impersonation copy
of the server key for the client, so that the NGFW remains an “invisible” proxy and the client
and server believe their session is with each other. Now, all parties have the certificates and
keys required and the NGFW can decrypt the traffic.
7. All SSL session traffic flows through the NGFW transparently between the client and the
server. The NGFW decrypts the SSL traffic, applies Security policy rules and security profiles
and decryption profiles to the traffic, reencrypts the traffic, and then forwards it.

When you configure SSL Forward Proxy, the proxied traffic does not support DSCP code
points or QoS.

Decryption Administration 31 ©2026 Palo Alto Networks, Inc.

Decryption Basics

SSL Inbound Inspection

Where Can I Use This? What Do I Need?

• No requirements.
•

Configure SSL Inbound Inspection to decrypt and inspect inbound SSL/TLS traffic from clients
to targeted network servers and block suspicious sessions. For example, suppose a malicious
actor wants to exploit a known vulnerability with your web server. Inbound SSL/TLS decryption
provides visibility into the traffic, enabling the Next-Generation Firewall (NGFW) to respond to
the threat proactively.
SSL Inbound Inspection works similarly to SSL Forward Proxy, except the direction of traffic it
focuses on differs. The NGFW acts as a meddler in the middle between an external client and
an internal server. The NGFW creates two separate and secure sessions: one between the client
and itself, and another between itself and the server. It also generates a new session key for each
secure session. SSL Inbound Inspection also supports SSL session resumption because the NGFW
functions as a proxy device.

The NGFW can't decrypt some sessions, such as sessions with client authentication or
pinned certificates, because it is a proxy device. It also doesn't support high availability
(HA) sync for decrypted SSL sessions.

SSL Inbound Inspection requires installation of the certificate and private key of each internal
server you want to protect onto the NGFW or management platforms for NGFW and Prisma
Access. The NGFW validates that the certificate sent by the targeted server during the SSL/TLS
handshake matches a certificate in your decryption policy rule. If there is a match, the NGFW
forwards the server certificate to the client requesting server access and establishes a secure
connection.
The TLS versions that your web server supports determine how you should install the server
certificate and key. If your web server supports TLSv1.2 and Rivest, Shamir, Adleman (RSA) or
Perfect Forward Secrecy (PFS) key exchange algorithms and your end-entity (leaf) certificate is
signed by intermediate certificates, we recommend uploading a certificate chain (a single file).
Uploading the chain avoids client-side server certificate authentication issues.

TLSv1.3 removes support for the RSA key exchange algorithm.

TLSv1.3 connections are handled differently than TLSv1.2 connections. During TLSv1.3
handshakes, the NGFW sends the client the same certificate or certificate chain that it receives
from the server. As a result, uploading the server certificate and private key to the NGFW is
sufficient if you correctly set up your web server. For example, if your server’s leaf certificate is
signed by intermediate certificates, install the chain of certificates on the server to avoid client-
side server authentication issues.

Decryption Administration 32 ©2026 Palo Alto Networks, Inc.

Decryption Basics

Multiple Certificate Support

SSL Inbound Inspection policy rules support up to 12 certificates, enabling you to update
certificates for protected internal servers without incurring downtime. A valid certificate
must always be present in your policy rules and on your servers for continuous decryption.
To add multiple certificates and maintain continuous decryption:
1. Renew or obtain a new certificate before your server certificate expires or otherwise
becomes invalid.
2. Import the certificate and private key onto the NGFW or management platforms for
NGFW and Prisma Access.
3. Add the certificate to the SSL Inbound Inspection policy rule.
4. Install the same certificate onto your web server. Load the certificate and check that
you've correctly installed it.
Updating a policy rule with a new certificate while another is active on your web server
enables decryption of incoming traffic regardless of the certificate in use. Installation
of the new certificate doesn't impact existing connections. The NGFW verifies that the
certificate in the Server Hello message matches the new certificate in the decryption
policy rule. If there isn't a match, the session ends. The corresponding decryption log
entry reports the session-end reason as a mismatch between the firewall and server
certificate. To view the server certificates used in all inbound inspection sessions, log
successful TLS handshakes.
Additional Use Case: Create decryption policy rules to inspect traffic to servers that host
various domains, each domain with its own certificate.
™
(Panorama ) Support for multiple certificates is unavailable in PAN-OS versions earlier
than PAN-OS 10.2. If you push an SSL Inbound Inspection policy rule with multiple
certificates from a Panorama management server running PAN-OS 11.1 to an NGFW
running an earlier version, the policy rule on the managed NGFW inherits only the first
certificate from the alphabetically sorted list of certificates.
(Recommended) Before pushing your decryption policy rule from Panorama, set up
different templates or device groups for NGFWs running PAN-OS 10.1 and earlier
versions to ensure you push the correct policy rule and certificate to the appropriate
NGFWs.

Create separate decryption profiles for servers with different security capabilities.
Configure the SSL Protocol Settings for the highest level of security that a server
supports, but consider performance to ensure that the NGFW and Prisma Access
resources can handle the higher processing load that higher security protocols and
algorithms require. For example, if a set of servers supports only RSA, configure a
decryption profile that exclusively supports RSA. If a server supports both RSA and PFS,
select RSA and PFS key exchange algorithms.

When you configure SSL Inbound Inspection, the proxied traffic does not support DSCP
code points or QoS.

Decryption Administration 33 ©2026 Palo Alto Networks, Inc.

Decryption Basics

SSH Proxy
Where Can I Use This? What Do I Need?

• Prisma Access (Managed by Panorama) No requirements.

• NGFW (Managed by PAN-OS or
Panorama)

In an SSH Proxy configuration, a Next-Generation Firewall (NGFW) sits between a client and
a server. Configuring SSH Proxy enables an NGFW to decrypt inbound and outbound SSH
connections, preventing attackers from using the SSH protocol to tunnel unwanted applications
and content. SSH decryption does not require certificates. The NGFW automatically generates
the key used for SSH connections when it boots up. During the boot-up process, the NGFW
checks for an existing key. If there isn't one, the NGFW generates a key. The NGFW uses the key
to decrypt SSH sessions for all virtual systems configured on it and all SSH v2 sessions.
SSH allows tunneling (or port forwarding), which is the transmission of data from a client to a
server over an encrypted connection. Bad actors can use SSH tunneling to hide malicious traffic
from decryption. The NGFW can't decrypt traffic inside an SSH tunnel. Instead, it identifies the
presence of an SSH tunnel using App-ID and, depending on your Security policy rules, blocks all
traffic in the tunnel.
SSH tunneling sessions can tunnel X11 Windows packets and TCP packets. A single SSH
connection can contain multiple channels. When you apply a decryption profile for SSH Proxy to
a Security policy rule that allows SSH traffic, the NGFW determines the App-ID of the traffic in
each channel to identify the channel type. The channel type can be:
• session
• X11
• forwarded-tcpip
• direct-tcpip
When the channel type is session, the NGFW identifies the traffic as allowed SSH traffic such
as SFTP or SCP. When the channel type is X11, forwarded-tcpip, or direct-tcpip, the NGFW
identifies the traffic as SSH tunneling traffic and blocks it. To block all traffic in an SSH tunnel,
configure a Security policy rule for the ssh-tunnel application with the Action set to Deny (along
with a Security policy rule that allows traffic from the ssh application).

To reduce your attack surface, limit SSH use to administrators who need to manage
network devices, log all SSH traffic, and consider enabling multi-factor authentication
(MFA) to ensure that only legitimate users can use SSH to access devices.

Decryption Administration 34 ©2026 Palo Alto Networks, Inc.

Decryption Basics

When SSH decryption is enabled, authenticating to hosts with a certificate fails. This
happens because the SSH client can no longer use public key authentication, preventing
the server from completing the TLS handshake using a public key that the client decrypts
with its private key. Use username and password authentication to initiate an SSH session
instead.
For systems that must use key-based authentication, configure your SSH decryption policy
rule to exclude systems that require public key authentication. To edit the decryption
policy rule:
1. Go to Policies > Decryption, and select the policy rule that controls SSH decryption.
2. Select the Destination tab.
3. Add the IP addresses of the systems you want to exclude from the rule.
4. Select Negate.
5. Click OK.
6. Commit your changes.

The following figure shows how SSH Proxy decryption works.

1. The client sends an SSH request to the server to initiate a session.

2. The NGFW intercepts the client’s SSH request.
3. The NGFW forwards the request to the server and initiates an SSH session with the server.
This establishes the first of two separate sessions that the NGFW creates. Each session
establishes a separate SSH tunnel.
4. The server responds to the request, which the NGFW intercepts.
5. The NGFW inserts the SSH key into the server’s response and forwards it to the client. This
establishes the second separate session (and separate SSH tunnel) that the NGFW creates.
6. (First part of “7” in the diagram) After the NGFW establishes separate sessions with the server
and the client, the NGFW acts as a proxy between them.

Decryption Administration 35 ©2026 Palo Alto Networks, Inc.

Decryption Basics

7. The NGFW checks the traffic between the client and server to see if it's routed normally or if
it uses SSH port forwarding (SSH tunneling). If the NGFW identifies SSH port forwarding, the
NGFW blocks the tunneled traffic and restricts it according to the configured Security policy
rule. The NGFW only looks for SSH port forwarding, it does not perform content and threat
inspection on SSH tunnels.

When you configure SSH Proxy, the proxied traffic does not support DSCP code points or
QoS.

Decryption Administration 36 ©2026 Palo Alto Networks, Inc.

Decryption Basics

TLS 1.3 Decryption

Where Can I Use This? What Do I Need?

• No requirements.
•

TLSv1.3 is the latest version of the TLS protocol, improving application security and performance.
Next-Generation Firewalls (NGFW and Prisma Access support TLSv1.3 for SSL Forward Proxy and
SSL Inbound Inspection decryption, decrypted Network Packet Broker traffic, and Decryption
Port Mirroring. This support enables you to decrypt, gain full visibility into, and prevent known
and unknown threats in TLSv1.3 traffic.
To support TLSv1.3 decryption, apply a decryption profile with TLSv1.3 configured as the
minimum or maximum protocol version to existing and new decryption policy rules. You can edit
existing decryption profiles to support TLSv1.3. If you don’t enable TLSv1.3, PAN-OS defaults to
TLSv1.2 as the maximum protocol version. If a website or application doesn't support TLSv1.3,
the Next-Generation Firewall (NGFW) automatically selects a TLS protocol version that the server
supports.
To establish a TLSv1.3 connection, both client and server must support negotiation with TLSv1.3
ciphers. The following decryption algorithms are supported for TLSv1.3 connections:
• TLS13-AES-128-GCM-SHA256
• TLS13-AES-256-GCM-SHA384
• TLS13-CHACHA20-POLY1305-SHA256
If the Max Version a decryption profile supports is Max, then the profile supports TLSv1.3 and
automatically uses TLSv1.3 with sites supporting this protocol. The Max option ensures that the
traffic that the profile controls uses the strongest available protocol version. It also future-proofs
the decryption profile as it provides automatic support for new TLS versions as they are released.

You can configure TLSv1.3 as the Max Version instead of Max. However, when the next
TLS version releases, you'll need to update the decryption profile.

Min Version specifies the weakest version of the protocol that the traffic can use. Setting the
minimum protocol version to TLSv1.3 achieves the tightest security because it requires traffic to
use TLSv1.3 or greater protocol versions. This blocks weaker protocols and makes weaker key
exchange, encryption, and authentication algorithms unavailable. Further, TLSv1.3 requires the
use of Perfect Forward Secrecy (PFS). Apply a profile that sets TLSv1.3 as the minimum version
only to application traffic that only supports [Link]
As not all applications support TLSv1.3, follow decryption best practices and set the Min Version
of the TLS protocol to TLSv1.2 and the Max Version to Max. If access to websites or applications
with weaker TLS protocols is a business requirement, create separate decryption profiles with
a Min Version that allows the weaker protocol and attach it to a decryption policy rule that
specifies the traffic you need to allow with the weaker TLS protocol.

Decryption Administration 37 ©2026 Palo Alto Networks, Inc.

Decryption Basics

For decryption policy rules that support mobile applications, many of which use pinned
certificates, set the Max Version to TLSv1.2. TLSv1.3 encrypts certificate information that was
not encrypted in previous TLS versions, preventing NGFWs from automatically adding decryption
exclusions based on certificate information. As a result, if you enable TLSv1.3, the NGFW may
drop some mobile application traffic. To mitigate potential issues, create a No Decryption policy
rule for this traffic. If you know the specific mobile applications required for business, consider
creating a separate decryption policy rule and decryption profile for those applications. This
approach allows you to enable TLSv1.3 for all other traffic.

Avoid attaching No-decryption profiles to decryption policy rules that exclusively

handle TLSv1.3 traffic. TLSv1.3 encrypts certificate information, so the NGFW doesn't
have visibility into this information and therefore can’t block sessions with expired
certificates or untrusted issuers, making the profile ineffective. (The NGFW can perform
certificate checks with TLSv1.2 and earlier protocols because those protocols don’t
encrypt certificate information. You should apply No Decryption profiles to decryption
policy rules handling TLSv1.2 and earlier traffic.) However, you can log undecrypted traffic
of all types by selecting the options to log successful and unsuccessful TLS handshakes in
decryption policy rules. Unsuccessful TLS handshakes are logged by default.

If you allow unsupported modes in the SSL Protocol Settings of a decryption profile, the NGFW
and Prisma Access automatically adds this traffic to its Local SSL Decryption Exclusion [Link]
NGFW and Prisma Access still decrypts and inspects traffic that is downgraded from TLSv1.3 to
TLSv1.2. The Reason shown in the cache for the added servers is TLS13_UNSUPPORTED.
If you downgrade from PAN-OS 11.1 to a previous version, any decryption profile that specifies
TLSv1.3 as the Min Version or the Max Version changes to the highest supported version. For
example, downgrading from PAN-OS 11.1 to PAN-OS 9.1 replaces TLSv1.3 with TLSv1.2. If a
Panorama device on PAN-OS 11.1 pushes the configuration to devices that run older versions
of PAN-OS, any decryption profile that specifies TLSv1.3 as the Min Version or the Max Version
also changes to the highest supported version.

Decryption Administration 38 ©2026 Palo Alto Networks, Inc.

Plan Your Decryption Deployment
Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

The most time-consuming part of deploying decryption isn’t configuring decryption policy rules
or decryption profiles. It is the preparation—working with stakeholders to decide what traffic to
decrypt, educating users about changes to website access, developing a public key infrastructure
(PKI) strategy, sizing your Next-Generation Firewall (NGFW) deployment, and planning each
phase of the decryption rollout.
Start by setting clear goals for your decryption deployment. You can evaluate each planning and
implementation phase against these goals. Ensure coordination between the teams involved in
implementation and affected users. Review the Decryption Planning Best Practices checklist, and
integrate best practices as much as you can. The best practice goal is to decrypt as much traffic as
your NGFW resources permit, prioritizing the most important traffic. In industries like healthcare
or finance, this goal should take into account regulatory requirements.

Migrate from port-based to application-based Security policy rules before creating and
deploying decryption policy rules. If you create decryption policy rules based on port-
based Security policy rules and then migrate to application-based Security policy rules,
the change could cause the decryption policy rules to block traffic that you intend to
allow because Security policy rules are likely to use application default ports to prevent
application traffic from using nonstandard ports.
For example, traffic identified as web-browsing (default port 80) may have underlying
applications with different default ports, such as HTTPS traffic (default port 443). The
application-default rule blocks the HTTPS traffic because the decrypted traffic uses a
nonstandard port (443 instead of 80). Migrating to App-ID based policy rules before
deploying decryption means that during proof of concept testing, you’ll discover Security
policy rule misconfigurations, and you can fix these issues before rolling it out to the
general user population.

To plan and implement a decryption deployment that minimizes risks, maximizes security benefits,
and accounts for business and legal requirements:
Develop a decryption strategy. Define clear objectives and what a successful deployment
looks like. Collaborate with stakeholders from legal, finance, HR, security, and IT teams.
Identify the traffic you want to prioritize for decryption. Consider traffic you may need to
exclude from decryption for technical, legal, or other reasons. Consider if you need to create
separate decryption policy rules or decryption profiles to handle traffic to and from various
user groups, devices, or applications.

39
Plan Your Decryption Deployment

Plan your PKI rollout. Proper certificate management and handling of user traffic is critical in
the decryption planning process. Consider which certificates you need and how to generate
them. Will you use an enterprise CA or a self-signed root CA certificate? Think about edge
cases, such as guest users or personal devices on your network. Ensure network devices have
valid certificates.
Size your NGFW to account for current and future needs. Decryption can be resource-
intensive. The amount of decryption an NGFW can support depends on various factors,
including volume of SSL traffic, TLS versions, cipher suites, and authentication methods.
Work with Palo Alto Networks representations to properly size deployments to meet your
requirements. Make sure your NGFW deployment can meet performance expectations when
decrypting at work.
Deploy decryption in phases. Plan each phase, including the education of stakeholders
and proof of concepts. Evaluate user experiences, generate decryption reports, and verify
effectiveness at each stage. Refine decryption policy rules and profiles as needed.
If enabling SSL/TLS decryption, use the Get Started with SSL Decryption resource as a guide
for an initial deployment. This topic includes steps for:
• creating a no-decryption policy rule to understand the websites and applications end users
access
• creating a low-risk proof of concept
• using decryption logs to identify and mitigate issues
Familiarize yourself with SSL decryption and use the insights from each step to turn a proof of
concept into a deployment aligned with business and other considerations.

Decryption Administration 40 ©2026 Palo Alto Networks, Inc.

Plan Your Decryption Deployment

Develop a Decryption Strategy

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Work with stakeholders such as legal, finance, HR, executives, security, and IT or support
personnel to develop a decryption deployment strategy. Start by getting the required approvals
to decrypt traffic to secure the corporation. Decrypting traffic involves understanding how legal
regulations and business needs affect what you can and can’t decrypt.
Identify and prioritize the traffic you want to decrypt. Best practice is to decrypt as much traffic
as you can to gain visibility into potential threats in encrypted traffic and prevent those threats.
If incorrect NGFW sizing prevents you from decrypting all the traffic you want to decrypt,
prioritize the most critical servers, the highest-risk traffic categories, and less trusted segments
and IP subnets. To help prioritize, ask yourself questions such as, “What happens if this server is
compromised?” and “How much risk am I willing to take in relation to the level of performance I
want to achieve?”
Identify traffic that you can’t decrypt because the traffic breaks decryption for technical reasons
such as a pinned certificate, an incomplete certificate chain, unsupported ciphers, or mutual
authentication. Decrypting sites that break decryption technically results in blocking that traffic.
Evaluate websites that break decryption technically and ask yourself if access to those sites
is needed for business reasons. If you don’t need access to those sites, allow decryption to
block them. If access to any of those sites is needed for business purposes, add them to the SSL
Decryption Exclusion list. The SSL Decryption Exclusion list is exclusively for sites that break
decryption technically.
Identify sensitive traffic that you choose not to decrypt for legal, regulatory, personal, or other
reasons, such as financial, health, or government traffic, or the traffic of certain executives. This
is not traffic that breaks decryption technically, so don’t use the SSL Decryption Exclusion list
to exclude this traffic from decryption. Instead, create a policy-based decryption exclusion to
identify and control traffic you choose not to decrypt and apply the no-decrypt decryption profile
to the policy rule to prevent servers with certificate issues from accessing the network. Policy-
based decryption exclusions are only for traffic you choose not to decrypt.
When planning your decryption policy, consider your company’s security compliance rules,
computer usage policy, and business goals. Strict controls can impact user experience by
preventing access to nonbusiness sites that users could previously access (and which may be
required for government or financial institutions). There is always a tradeoff between usability,
management overhead, and security. The tighter the decryption policy, the greater the chance
that a website will become unreachable, which may result in user complaints and the need to
modify the rulebase.

Decryption Administration 41 ©2026 Palo Alto Networks, Inc.

Plan Your Decryption Deployment

Use complaints as a tool to better understand the traffic on your network. Although a
tight decryption policy may initially cause a few user complaints, those complaints can
draw your attention to unsanctioned or undesirable websites that are blocked because
they use weak algorithms or have certificate issues.

Different groups of users and individuals may require different decryption policy rules, or you
may want to apply the same rules to all users. For example, executives may be exempted from
decryption policy rules that apply to other employees. You may also want to apply different rules
to employee groups, contracts, partners, and guests. Prepare updated legal and HR computer
usage policies for distribution to all employees, contractors, partners, guests, and any other
network users so that when you roll out decryption, users understand their data can be decrypted
and scanned for threats.

How you handle guest users depends on the access they require. Isolate guests from the
rest of your network by placing them on a separate VLAN and a separate SSID for wireless
access. If guests don’t need to access your corporate network, restrict their access. There
will be no need to decrypt their traffic. If guests need to access your corporate network,
decrypt their traffic.
• Enterprises don’t control guest devices. Decrypt guest traffic and subject it to your
guest Security policy rules so the NGFW inspects the traffic and prevents threats. To
do this, redirect guest users through an Authentication Portal, instruct them how to
download and install the CA certificate, and clearly notify guests that their traffic will
be decrypted. Include this process in your company’s privacy and computer usage
policy.
• Create separate decryption policy rules and Security policy rules to limit their access
to the areas of your network that they need to access.

Decide which devices, websites, and applications to decrypt. Today’s networks support not
only corporate devices, but BYOD, mobile, remote-user and other devices, including contractor,
partner, and guest devices. Today’s users attempt to access many sites, both sanctioned and
unsanctioned, and you should decide how much of that traffic you want to decrypt.

Enterprises don’t control BYOD devices. If you allow BYOD devices on your network,
decrypt their traffic and subject it to the same Security policy rules that you apply to
other network traffic so the NGFW can inspect the traffic and prevent threats. To do this,
redirect BYOD users through an Authentication Portal, instruct them how to download
and install the CA certificate, and clearly notify users that their traffic will be decrypted.
Educate BYOD users about the process and include it in your company’s privacy and
computer usage policy.

Decide what traffic to log, and investigate what traffic you can log. Be aware of local laws
regarding data logging and storage, including where you can log and store the data. For example,
local laws may prevent the logging and storing of personal information such as health and financial
data.
Decide how to handle bad certificates. For example, will you block or allow sessions for which
the certificate status is "unknown"? Understanding your approach to bad certificates will help you
configure the decryption profiles that you attach to decryption policy rules to control the sessions
you allow based on server certificate verification status.

Decryption Administration 42 ©2026 Palo Alto Networks, Inc.

Plan Your Decryption Deployment

Plan a Public Key Infrastructure (PKI) Rollout

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Plan how to roll out your public key infrastructure (PKI). Network devices need an SSL Forward
Trust certificate authority (CA) certificate for trusted sites and an SSL Forward Untrust CA
certificate for untrusted sites. Generate separate Forward Trust and Forward Untrust certificates.
Don't sign the Forward Untrust certificate with the enterprise root CA because you want the
Untrust certificate to warn users that they are trying to access potentially unsafe sites. Palo Alto
Networks Next-Generation Firewalls (NGFWs) have two methods of generating CA certificates
for SSL decryption:
• Generate the SSL CA certificates from your enterprise root CA as subordinate certificates—
If you have an existing enterprise PKI, this is the best practice. Generating a subordinate
certificate from your enterprise root CA makes the rollout easier and smoother because
network devices already trust the enterprise root CA, so you avoid any certificate issues when
you begin the deployment phase. If you don't have an enterprise root CA, consider getting one.
• Generate a self-signed root CA certificate on the NGFW and create subordinate CA
certificates on that NGFW—If you don't have an enterprise root CA, this method provides a
self-signed root CA certificate and the subordinate Forward Trust and Untrust CA certificates.
With this method, you need to install the self-signed certificates on all of your network devices
so that those devices recognize the NGFW’s self-signed certificates. Because the certificates
must be deployed to all devices, this method is better for small deployments and proof of
concept (PoC) trials than for large deployments.

Don't export the Forward Untrust certificate to the certificate trust lists of your network
devices. Installing the Untrust certificate in the Trust List results in devices trusting
websites that the NGFW does not trust. In addition, users won't see certificate warnings
for untrusted sites, so they won't know the sites are untrusted and may access those sites,
which could expose your network to threats.

Regardless of whether you generate Forward Trust certificates from your enterprise
root CA or use a self-signed certificate generated on the NGFW, generate a separate
subordinate Forward Trust CA certificate for each NGFW. The flexibility of using separate
subordinate CAs enables you to revoke one certificate when you decommission a device
(or device pair) without affecting the rest of the deployment. It also reduces the impact
in any situation in which you need to revoke a certificate. Separate Forward Trust CAs
on each NGFW also helps troubleshoot issues because the CA error message the user
sees includes information about the NGFW the traffic is traversing. If you use the same
Forward Trust CA on every NGFW, you lose the granularity of that information.

Decryption Administration 43 ©2026 Palo Alto Networks, Inc.

Plan Your Decryption Deployment

There is no benefit to using different Forward Untrust certificates on different NGFWs, so you
can use the same Forward Untrust certificate on all NGFWs. If you need additional security for
your private keys, consider storing them on a hardware security module.
You may need to make special accommodations for guest users. If guest users don't need access
to your corporate network, don't allow access, and then you won't have to decrypt their traffic
or create infrastructure to support guest access. If you need to support guest users, discuss with
your legal department whether you can decrypt guest traffic.
If you can decrypt guest traffic, treat guests similarly to the way you treat BYOD devices. Decrypt
guest traffic and subject it to the same Security policy that you apply to other network traffic. Do
this by redirecting guest users through an Authentication Portal, instruct them how to download
and install the CA certificate, and clearly notify users that their traffic will be decrypted. Include
the process in your company’s privacy and computer usage policy. In addition, restrict guest traffic
to only the areas guests need to access.
If you can’t decrypt guest traffic for legal reasons, then isolate guest traffic and prevent it from
moving laterally in your network:
• Create a separate zone for guests and restrict guest access to that zone. To prevent lateral
movement, don’t allow guest access to other zones.
• Allow only sanctioned applications, use URL filtering to prevent access to risky URL categories,
and apply the best practice Security profiles.
• Prevent guests from accessing websites with unknown or expired CAs by enabling the block
sessions with untrusted issuers and block sessions with expired certificates options in your
decryption profiles.
All employees, contractors, partners, and other users should use your normal corporate
infrastructure, and you should decrypt and inspect their traffic.

Decryption Administration 44 ©2026 Palo Alto Networks, Inc.

Plan Your Decryption Deployment

Size Next-Generation Firewalls for Decryption

Requirements
Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Decrypting encrypted traffic consumes Next-Generation Firewall (NGFW) CPU resources and can
affect throughput. In general, the tighter the security (the more SSL traffic you decrypt combined
with the more stringent your protocol settings), the more NGFW resources decryption consumes.
Work with your Palo Alto Networks SE or CE to size your NGFW deployment and avoid sizing
mistakes. Factors that affect decryption resource consumption and therefore how much traffic
you can decrypt include:
• The amount of SSL traffic you want to decrypt. This varies from network to network. For
example, some applications must be decrypted to prevent the injection of malware or exploits
into the network or unauthorized data transfers, some applications can’t be decrypted
due to local laws and regulations or business reasons, and other applications are cleartext
(unencrypted) and don’t need to be decrypted. The more traffic you want to decrypt, the more
resources you need.
• The TLS protocol version. Higher versions are more secure but consume more resources. Use
the highest TLS protocol version you can to maximize security.
• The key size. The larger the key size, the better the security, but also the more resources the
key processing consumes.
• The key exchange algorithm. Perfect Forward Secrecy (PFS) ephemeral key exchange
algorithms such as Diffie-Hellman Ephemeral (DHE) and Elliptic-Curve Diffie-Hellman
Exchange (ECDHE) consume more processing resources than Rivest-Shamir-Adleman (RSA)
algorithms. PFS key exchange algorithms provide greater security than RSA key exchange
algorithms because the NGFW generates a new cipher key for each session. If an attacker
compromises a session key, PFS prevents the attacker from using it to decrypt any other
sessions between the same client and server. Generating the new key, however, consumes
more NGFW resources.
• The encryption algorithm. The key exchange algorithm determines whether the encryption
algorithm is PFS or RSA.

Decryption Administration 45 ©2026 Palo Alto Networks, Inc.

Plan Your Decryption Deployment

• The certificate authentication method. RSA (not the RSA key exchange algorithm) consumes
less resources than Elliptic Curve Digital Signature Algorithm (ECDSA), but ECDSA is more
secure.

The combination of the key exchange algorithm and the certificate authentication
method affect throughput performance as shown in RSA and ECDSA benchmark tests.
The performance cost of PFS trades off against the higher security that PFS achieves,
but PFS may not be needed for all types of traffic. You can save NGFW CPU cycles
by using RSA for traffic that you want to decrypt and inspect for threats but that isn’t
sensitive.
• Average transaction sizes. For example, small average transaction sizes consume more
processing power to decrypt. Measure the average transaction size of all traffic, then measure
the average transaction size of traffic on port 443 (the default port for HTTPS encrypted
traffic) to understand the proportion of encrypted traffic going to the NGFW in relation to your
total traffic and the average transaction sizes. Eliminate anomalous outliers such as unusually
large transactions to get a truer measurement of average transaction size.
• The NGFW model and resources. Newer NGFW models have more processing power than
older models.
The combination of these factors determines how decryption consumes NGFW processing
resources. To best use the NGFW’s resources, understand the risks of the data you’re protecting.
If NGFW resources are an issue, use stronger decryption for higher-priority traffic and use less
processor-intensive decryption for lower-priority traffic until you can increase the available
resources. For example, you could use RSA instead of ECDHE and ECDSA for traffic that isn’t
sensitive or high-priority. This preserves NGFW resources for PFS-based decryption of higher
priority, sensitive traffic. (You’re still decrypting and inspecting the lower-priority traffic, but
trading off consuming fewer computational resources with using algorithms that aren’t as secure
as PFS.) The key is to understand the risks of different traffic types and treat them accordingly.
Measure NGFW performance to understand the currently available resources and determine
whether you need more resources to decrypt the traffic you want to decrypt. Measuring NGFW
performance also sets a baseline for performance comparisons after deploying decryption. You
can also run a proof of concept.
Size your NGFW deployment based on current and future needs. Include headroom for the
growth of decryption traffic. Gartner predicts that through 2019, more than 80 percent of
enterprise web traffic will be encrypted, and more than 50 percent of new malware campaigns
will use various forms of encryption. Work with your Palo Alto Networks representatives to help
you size your deployment.

Decryption Administration 46 ©2026 Palo Alto Networks, Inc.

Plan Your Decryption Deployment

Deploy Decryption in Stages

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Plan to roll out decryption in a controlled manner, piece by piece. Don’t roll out your entire
decryption deployment at once. Test and ensure that decryption is working as planned and that
users understand what you're doing and why. Rolling out decryption in this manner makes it
easier to troubleshoot in case anything doesn’t work as expected and helps users adjust to the
changes.
Educating stakeholders, employees, and other users such as contractors and partners is critical
because decryption settings may change their ability to access some websites, especially risky
or nonbusiness critical ones. Users should understand how to respond to situations in which
previously reachable websites become unreachable and what information to give to technical
support. Support should understand what is being rolled out when and how to help users who
encounter issues.
Before you roll out decryption to the general population:
• Identify early adopters to help champion decryption and who will be able to help other
employees who have questions during the full rollout. Enlist the help of department managers
and help them understand the benefits of decrypting traffic.
• Set up proof of concept (PoC) trials in each department with early adopters and other
employees who understand why decrypting traffic is important. Educate PoC participants
about the changes and how to contact technical support if they run into issues. In this way,
a decryption PoC becomes an opportunity to work with technical support to PoC how to
support decryption and develop the most painless method for supporting the general rollout.
The interaction between PoC participants and technical support also allows you to fine-tune
decryption policy rules and how to communicate with users.
The PoC enables you to experiment with prioritizing what to decrypt first, so that when you
phase in decryption in the general population, you understand how to phase in decryption
of different URL categories. Measure the way decryption affects Next-Generation Firewall
(NGFW) CPU and memory utilization to help understand if the NGFW sizing is correct or if
you need to upgrade. The PoC can also reveal applications that break decryption technically
(decrypting them blocks their traffic) and should be added to the SSL Decryption Exclusion List.
When you set up proof of concepts, also set up a user group that can certify the operational
readiness and procedures prior to the general rollout.
• Educate the user population before the general rollout, and plan to educate new users as they
join the company. This is a critical phase of deploying decryption because the deployment
may affect websites that users previously visited but are not safe, so those sites are no longer
reachable. The PoC experience helps identify the most important points to communicate.

Decryption Administration 47 ©2026 Palo Alto Networks, Inc.

Plan Your Decryption Deployment

• Phase in decryption. You can accomplish this in several ways:

• Decrypt the highest priority traffic first (for example, the URL categories most likely to
harbor malicious traffic, such as gaming) and then decrypt more as you gain experience.
• Take a more conservative approach and decrypt the URL categories that don’t affect your
business first (for example, news feeds), so if something goes wrong, no issues occur that
affect your business.
In all cases, the best way to phase in decryption is to do the following:
• Decrypt a few URL categories
• Take user feedback into account
• Run reports to ensure that decryption is working as expected (if possible)
• Gradually decrypt a few more categories, verify, and so on
Additional Considerations:
• Plan to make decryption exclusions for traffic you can’t decrypt for technical reasons or that
you choose not to decrypt.
• If you enable users to opt out of SSL decryption (users see a response page that allows them
either to opt out of decryption and end the session without going to the site or to proceed
to the site and agree to have the traffic decrypted), educate them about what it is, why
they’re seeing it, and what their options are.
• Create realistic deployment schedules that allow time to evaluate each stage of the rollout.

Place NGFWs in positions where they can see all network traffic so that no encrypted
traffic inadvertently gains access to your network because it bypasses the NGFW.

Decryption Administration 48 ©2026 Palo Alto Networks, Inc.

Enable Decryption
Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Enable decryption for visibility into traffic passing through your network—potential threats,
unwanted traffic, and other anomalies that might otherwise go unexamined. Decryption involves
the conversion of encrypted traffic to plaintext for deep inspection. The Next-Generation Firewall
(NGFW) inspects the traffic and applies relevant decryption policy rules and profiles. Traffic is re-
encrypted before it exits the NGFW. Many services rely on and enhance decryption capabilities,
including Advanced URL Filtering, Advanced Threat Prevention, and Advanced WildFire®. You
can't protect your network against threats you can't see. Reasons to enable decryption include
preventing the exfiltration of sensitive data, ensuring legal or regulatory compliance, and enabling
filtering of HTTPS websites.

Enabling decryption impacts throughput performance. To correctly size NGFWs, identify

traffic to prioritize for decryption, run a proof of concept, and work with Palo Alto
Networks experts.

A best practice decryption deployment aims to decrypt as much traffic as possible the traffic,
while properly managing undecrypted traffic. The following high-level steps are key to building a
robust, informed decryption deployment.
Plan your decryption deployment. You might block legitimate traffic if you don't have a well
thought out decryption policy.
(SSL decryption) Follow the steps to get started with SSL decryption, which will help with
planning and policy refinement before widespread implementation.
(SSL decryption) Prepare required keys and certificates. SSL Decryption Deployment Best
Practices describes best practices for generating and distributing keys and certificates.
Define traffic to decrypt and not to decrypt in a decryption policy rule.
• (Best Practice) Block URL filtering categories that are known to be dangerous, such as
malware, phishing, dynamic-dns, unknown, command-and-control, proxy-avoidance-and-
anonymizers, copyright-infringement, extremism, newly-registered-domain, grayware, and
parked. If you must allow any of these categories for business reasons, decrypt them and
apply strict Security profiles to the traffic.
• (Best Practice) Decrypt the following URL categories if you allow them: online-storage-and-
backup, web-based-email, web-hosting, personal-sites-and-blogs, and content-delivery-
networks.
• Add websites that can't be decrypted for technical reasons to the SSL decryption exclusion
list.

49
Enable Decryption

Apply granular settings to traffic matching decryption policy rules. Decryption profiles allow
you to configure certificate checks, session mode checks, failure checks, and protocol and
algorithm checks, depending on the decryption type. These checks prevent risky connections,
such as sessions with untrusted certificate issuers, weak protocols, ciphers, and algorithms, and
servers that have certificate issues.
Decryption deployment best practices checklist provides a comprehensive list of best practices
for each step of the way.

Decryption Administration 50 ©2026 Palo Alto Networks, Inc.

Enable Decryption

Get Started with SSL Decryption

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

This topic intends to provide a quick and easy procedure for onboarding SSL decryption,
particularly for SSL Forward Proxy use cases. It focuses on deploying decryption in a phased,
risk-free manner enabling you to avoid the edge cases normally seen with decryption. It does
not provide best practices for optimal decryption configuration. Your needs may vary and thus
the procedure should be used as a guide. Review Plan Your Decryption Deployment and the
Decryption Best Practices guide before, during, and after creating your proof of concept.
STEP 1 | Configure a “blanket” No Decrypt decryption policy rule with lenient settings, including:
This will help you better understand the websites and apps your users access.
1. Select Any for the following Source, Destination, and Service/URL Category settings:
Source User, Source Device, Destination Address, Destination Device, Service, and URL
Category.
2. Select Options, and then for Action, select No Decrypt.
3. Under Log Settings, select Log Successful SSL Handshake to view cryptography
information in the decryption logs.
4. Attach a decryption profile without any Server Certificate Verification settings selected
to the no-decrypt decryption policy rule.
5. Commit your changes.

STEP 2 | Inspect your decryption logs.

Search the decryption logs for the following:
• Usage of vulnerable cryptographic protocols (for example, TLSv1.1 or earlier).
To secure your network, set your decryption profile to block vulnerable ciphers.
• Expired or invalid certificate usage.
• Any errors or unexpected issues.

Prioritize the following log fields in your search: Encryption Algorithm, TLS Version, Key
Exchange, Error, Server Name Indication, Certificate End Date.

Refer to the Troubleshoot Decryption chapter for details on how to search through decryption
logs, identify vulnerable ciphers and invalid certificates, as well as troubleshoot decryption
errors. For a list of errors you might encounter in your logs and possible remediation, see
Decryption Log Errors and Error Indexes.

Decryption Administration 51 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 3 | Load or generate a CA certificate on the NGFW, Prisma Access, or management interface.

Limit the use of self-signed certificates where possible; instead, use preexisting
certificates that client browsers already trust.

STEP 4 | Identify a small group of users (5-10) in your network to test and validate a decryption proof
of concept.
Ideal users are familiar with the technology and are willing and able to provide feedback, such
as a member of the IT organization.

STEP 5 | Create your proof of concept.

1. Create decryption profiles using SSL decryption best practices.
• Block insecure sessions–sessions with expired certificates, untrusted issuers,
unsupported versions, and unsupported cipher suites.
• Block sessions with client authentication unless an important application requires it,
in which case you should create a separate decryption profile for those applications.
• Use the strongest ciphers that you can. For SSL Forward Proxy, set the minimum
protocol version to TLSv1.2 and the maximum version to Max to block weak
protocols. For SSL Inbound Inspection, create separate profiles that match the ciphers
that your servers support.
2. Create a new decryption policy rule.
• For Source User, Add the group of users who are part of the proof of concept.
• Block access to a small subset of URLs or URL categories, such as categories that Palo
Alto Networks has identified as risky. Decrypting a small subset makes the rule easier
to phase in.
• Create specific decryption policy rules and profiles for applications that use less
secure ciphers and protocols (for example, TLSv1.1), so that the security of other
application traffic isn't affected.

STEP 6 | Launch your proof of concept (PoC).

Continuously monitor feedback and issues from your test users. For your first set of 5-10
users, we suggest running the proof of concept for at least two weeks to ensure any issues
from normal network traffic arise.

STEP 7 | Expand your proof of concept to a larger group (100+ users).

Make sure it is a diverse group; the network traffic of these users should be representative of
that of the organization at large.
We suggest running this for 2-4 weeks to surface any issues. You may need to account for
applications used for recurring periodical events (for example, quarterly meetings).

STEP 8 | Refine your decryption policy rules as necessary.

Decryption Administration 52 ©2026 Palo Alto Networks, Inc.

Enable Decryption

Define Traffic to Decrypt

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Decryption policy rules define the traffic that you decrypt or do not decrypt. You can craft
granular rules based on network and policy objects, including source, destination, service
(application port), URL category, and users. Decryption policy rules also define the type of
decryption performed: SSL Forward Proxy, SSL Inbound Inspection, or SSH Proxy. Additionally,
you can enable Decryption Mirroring, decryption log settings, and additional controls, such as
checks for expired certificates by applying a decryption profile to a rule.

Best Practices and Considerations for Decryption Policy Rules

Strike a balance between thorough inspection and efficient performance, compliance, security,
and resource management. Decrypting all traffic indiscriminately can be resource-intensive. For
example, if Next-Generation Firewall (NGFW) performance and sizing are major considerations,
you might prioritize the decryption and inspection of traffic to high- or medium-risk URL
categories, traffic destined for critical servers, or business-critical traffic. Evaluate the potential
impacts of decryption on major applications or servers.
In another case, you might decide not to decrypt the traffic of high-level business executives. You
can do so by creating a no-decrypt decryption policy rule with the executive's User-ID as a source.
Create targeted decryption policy rules for different network segments and user groups.
Different segments of the network may have varying levels of risk and security requirements.
For example, traffic between external networks and internal zones typically requires stricter
scrutiny. Decrypting traffic selectively allows the implementation of customized security policies
that provide appropriate levels of protection without compromising performance or privacy for
other users. Use the controls available to create targeted decryption policy rules that take into
account the most important factors to you. You might even update your decryption policy rules to
optimize troubleshooting efforts.
Create rules that are as specific or general as needed and order them appropriately. Many
Palo Alto Networks services rely on decryption. Clearly define which types of traffic should be
decrypted, ensuring that the rules are specific enough to be effective but broad enough to cover
necessary use cases.

Place rules that exclude traffic from decryption at the top. Decryption policy rules are
compared against the traffic in sequence. Decryption policy rules are evaluated from top
to bottom; more specific rules must precede more general rules.

Exclude certain traffic from decryption. Create a no-decrypt policy rule for traffic that you choose
not to decrypt for business, legal, regulatory, or other reasons. For traffic that breaks decryption

Decryption Administration 53 ©2026 Palo Alto Networks, Inc.

Enable Decryption

for technical reasons, such as certificate pinning, add the server to the SSL decryption exclusion
list.
Best Practices:
• Block known dangerous URL filtering categories such as malware, phishing, dynamic-dns,
unknown, command-and-control, proxy-avoidance-and-anonymizers, copyright-infringement,
extremism, newly-registered-domain, grayware, and parked. If you must allow any of these
categories for business reasons, decrypt them and apply strict Security profiles to the traffic.
• URL categories that you should always decrypt if you allow them include: online-storage-
and-backup, web-based-email, web-hosting, personal-sites-and-blogs, and content-delivery-
networks.
• Apply a decryption profile to decryption policy rules to protect your network against encrypted
threats. You can’t protect yourself against threats you can’t see.
Deploy SSL Decryption Using Best Practices provides additional best practices.

In Security policy rules, block the Quick UDP Internet Connections (QUIC) protocol unless
you want to allow encrypted browser traffic for business reasons. Chrome and some other
browsers establish sessions using QUIC instead of TLS. QUIC uses proprietary encryption
that NGFWs can’t decrypt, so potentially dangerous traffic may enter the network as
encrypted traffic. Blocking QUIC forces the browser to fall back to TLS and enables de
ryption of the traffic.
Create a Security policy rule that blocks QUIC on its UDP service ports (80 and 443) and
create a separate rule that blocks the QUIC application. For the rule that blocks UDP
ports 80 and 443, create a Service that includes UDP ports 80 and 443.

Before creating a decryption policy rule, understand that the set of IPv4 addresses is
treated as a subset of the set of IPv6 addresses, as described in detail in Policy.

• Strata Cloud Manager

• PAN-OS & Panorama

Define Traffic to Decrypt (Strata Cloud Manager)

STEP 1 | Log in to Strata Cloud Manager.

STEP 2 | Add a new decryption policy rule.

1. Select Configuration > NGFW and Prisma Access > Security Services > Decryption.
2. In the Decryption Policies section, click Add Rule.

Decryption Administration 54 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 3 | Provide basic information to identify the rule.

1. Enter a descriptive Name.
2. (Optional) Enter a Description of the rule.
3. (Optional) Select a Position.
4. (Optional) Select Tags.

STEP 4 | Specify match criteria based on network and policy objects.

A rule only applies to traffic that matches all specified criteria.
• Configure the following Source and Destination settings to enforce traffic based on its
origin or where it terminates:
• Zones—Click Add Zones, then select existing Zones (for example, Internet), or click the
down arrow and select Any Zone. You can also create a zone.
• Addresses—Click Add Addresses, then select existing Addresses, or click the down arrow
and select Any Address. You can also add Address Groups, External Dynamic Lists, and
Regions, or (Destination section) SaaS Application Endpoints.
To exclude Address objects from decryption:
1. Specify at least one address, address group, external dynamic list, or region.
2. Select Exclude (Negate).
• Users—Click Add User Groups or Add Users, then select existing user groups or local
users, or click Add Local User Groups or Add Local Users to create new user groups or
users.
You can also decrypt traffic for Any User or certain types of users: Match pre-logon
(users who are connected to GlobalProtect but are not yet logged in), Match known-
user, or Match unknown.
• Devices—Click Add Device Profiles or (Source section) Add HIP Profiles, then select
existing profiles or in the case of HIP Profiles, create a Host Information profile. You can
also select Any or Match no-hip.
• Configure Services and URLs settings to match traffic based on service (port and protocols)
or URL categories:
• Service Entities—Click Add Services or Add Service Groups, then either select existing
services or service groups or click Create New to create a new entity.
By default, decryption policy rules decrypt any traffic on TCP and UDP ports. However,
you can click the down arrow and select Any Service, if necessary. To match applications
on the default application ports, click the down arrow and select application-default.

The application-default setting can be useful when you create a policy-based

decryption exclusion. You can exclude applications running on their default
ports from decryption, while continuing to decrypt the same applications if they
are detected on nonstandard ports.
• URL Category Entities—Click Add URL Categories, then select existing URL categories or
click Create New. To apply the rule to any URL category, click the down arrow and select
Any URL Category. You can also Add External Dynamic Lists and SaaS Application

Decryption Administration 55 ©2026 Palo Alto Networks, Inc.

Enable Decryption

Endpoints. To create a new external dynamic list while configuring the rule, click Create
New.

STEP 5 | Specify how to handle traffic that matches rule conditions.

1. In the Action and Advanced Inspection section, for Action, select either Decrypt or Do
Not Decrypt.
If you selected Decrypt, select a decryption Type:
• SSL Forward Proxy.
• SSL Inbound Inspection. Then, Add one or more Certificates for the internal server
you want to protect. Decryption policy rules for SSL Inbound Inspection support a
maximum of 12 certificates.

You can decrypt SSL/TLS traffic bound for an internal server that hosts
multiple domains, each domain with its own certificate. The NGFW
negotiates SSL/TLS connections using the certificate in your policy rule that
matches the one the server presents for the requested URL.

To update certificates for protected internal servers without incurring

downtime, renew or obtain a new server certificate before it expires or
otherwise becomes invalid. Then, import the certificate and private key onto
your NGFW or Strata Cloud Manager, add it to an SSL Inbound Inspection
policy rule before installing the same certificate onto your web server.
Updating your policy rule with a new certificate while another is active
on your web server prepares the NGFW to decrypt traffic to the server
regardless of the certificate in use. Configure SSL Inbound Inspection
describes this process further.
If you selected Do Not Decrypt, you can optionally Enforce TLS and Certificate
Validation.
2. (Optional) Associate a decryption profile with the decryption policy rule to block and
control various aspects of traffic governed by the decryption policy rule.
1. Create or modify a decryption profile.
2. Under Action and Advanced Inspection, select a Decryption Profile.
For SSL decryption, you can define the TLS protocol versions, key exchange algorithms,
encryption algorithms, and authentication algorithms allowed for SSL Forward Proxy and
SSL Inbound Inspection connections. You can also block sessions with weak protocol
versions, expired certificates, and other options.
The profile settings the NGFW applies to matching traffic depends on the policy rule
action (Decrypt or Do Not Decrypt) and decryption type (SSL Forward Proxy and
SSL Inbound Inspection). This allows you to use the different decryption profiles with
different decryption policy rules that apply to different types of traffic and users.

STEP 6 | Configure decryption logging.

You can log successful and unsuccessful TLS handshakes and configure external log
forwarding.

STEP 7 | Save the decryption policy rule.

Decryption Administration 56 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 8 | Click Push Config to begin enforcing the rule.

STEP 9 | Test your decryption configuration, and make any necessary adjustments.

STEP 10 | Choose your next step:

• Configure SSL Forward Proxy.
• Configure SSL Inbound Inspection.
• Create policy-based decryption exclusions for traffic you choose not to decrypt.
• Add sites that break decryption for technical reasons such as pinned certificates or mutual
authentication to the SSL decryption exclusion list.

Define Traffic to Decrypt (PAN-OS & Panorama)

STEP 1 | Add a new decryption policy rule.
Select Policies > Decryption, Add a new decryption policy rule, and give the policy rule a
descriptive Name.

STEP 2 | Configure the decryption rule to match to traffic based on network and policy objects:
• Firewall security zones—Select Source or Destination and match to traffic based on the
Source Zone or Destination Zone.
• IP addresses, address objects, or address groups—Select Source or Destination to match
to traffic based on the Source Address or the Destination Address. Alternatively, select
Negate to exclude the source address list from decryption.

(Available in PAN-OS 12.1.2 and later) If your network operates using IPv6 (or a
dual stack deployment) and would like to specify a region with IPv6 geolocation for
the source and destination IP addresses, you must Enable IPv6 Firewalling as well
as Enable IPv6 Geolocation from Device > Sessions > Session Settings.
The following platforms configured with less than 9GB do not support IPv6
geolocation:
• Hardware NGFWs: PA-410, PA-410R, PA-410R-5G, PA-415, and PA-415-5G
• VM-Series: Software NGFW Credits and VM-Series models with less than
9GB (e.g. VM-100, VM-50, etc)
• Users—Select Source and set the Source User for whom to decrypt traffic. You can decrypt
specific user or group traffic or decrypt traffic for certain types of users, such as unknown
users or pre-logon users (users who are connected to GlobalProtect but are not yet logged
in).
• Ports and protocols—Select Service/URL Category to set the rule to match to traffic based
on service. By default, the policy rule is set to decrypt Any traffic on TCP and UDP ports.

Decryption Administration 57 ©2026 Palo Alto Networks, Inc.

Enable Decryption

You can Add a service or a service group, and optionally set the rule to application-default
to match to applications only on the application default ports.

The application-default setting can be useful when you create a policy-based

decryption exclusion. You can exclude applications running on their default ports
from decryption, while continuing to decrypt the same applications when they are
detected on nonstandard ports.

• URLs and URL categories—Select Service/URL Category and decrypt traffic based on:
• An externally hosted list of URLs that the NGFW retrieves for policy-enforcement (see
Objects > External Dynamic Lists).
• Palo Alto Networks predefined URL categories, which make it easy to decrypt entire
categories of allowed traffic. This option is also useful when you create policy-based
decryption exclusions because you can exclude sensitive sites by category instead of
individually. For example, although you can create a custom URL category to group sites
that you do not want to decrypt, you can also exclude financial or healthcare-related
sites from decryption based on the predefined Palo Alto Networks URL categories. In
addition, you can block risky URL categories and create comfort pages to communicate
the reason the sites are blocked, or enable users to opt out of SSL decryption.
You can use the predefined high-risk and medium-risk URL categories to create a
decryption policy rule that decrypts all high-risk and medium-risk URL traffic. Place the
rule at the bottom of the rulebase (all decryption exceptions must be above this rule so
that you don’t decrypt sensitive information) as a safety net to ensure that you decrypt
and inspect all risky traffic. However, if high-risk or medium-risk sites to which you allow
access contain personally identifiable information (PII) or other sensitive information
that you don’t want to decrypt, either block those sites to avoid allowing encrypted risky
traffic while also avoiding privacy issues or create a no- decrypt policy rule to handle the
sensitive traffic.
• Custom URL categories (see Objects > Custom Objects > URL Category). For example,
you can create a custom URL category to specify a group of sites you need to access for
business purposes but that don't support the safest protocols and algorithms, and then
apply a customized decryption profile to allow the weaker protocols and algorithms for
just those sites (that way, you don’t decrease security by downgrading the decryption
profile you use for most sites).

Decryption Administration 58 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 3 | Set the rule to either decrypt matching traffic or to exclude matching traffic from decryption.
Select Options and set the policy rule Action:
To decrypt matching traffic:
1. Set the Action to Decrypt.
2. Select the Type of decryption:
• SSL Forward Proxy.
• SSL Inbound Inspection. Then, Add one or more Certificates for the destination
internal server of the inbound SSL traffic. SSL Inbound Inspection policy rules support
a maximum of 12 certificates.

You can configure a decryption policy rule to decrypt SSL/TLS traffic bound
for an internal server that hosts multiple domains, each domain with its own
certificate. The NGFW negotiates SSL/TLS connections using the certificate
in your policy rule that matches the one the server presents for the requested
URL.

To update certificates for protected internal servers without incurring

downtime, renew or obtain a new server certificate before it expires or
otherwise becomes invalid. Then, import the certificate and private key onto
your NGFW or Strata Cloud Manager, add it to an SSL Inbound Inspection
policy rule before installing the same certificate onto your web server.
Updating your policy rule with a new certificate while another is active
on your web server prepares the NGFW to decrypt traffic to the server
regardless of the certificate in use. Configure SSL Inbound Inspection
describes this process further.
™
(Panorama ) Support for multiple certificates in SSL Inbound Inspection
®
policy rules is unavailable in PAN-OS versions earlier than PAN-OS 10.2.
If you push an SSL Inbound Inspection policy rule with multiple certificates
from a Panorama management server running PAN-OS 10.2 to a NGFW
running an earlier version, the policy rule on the managed NGFW inherits
only the first certificate from the alphabetically sorted list of certificates.
Before pushing your decryption policy rule from Panorama, we recommend
you set up different templates or device groups for NGFWs running
PAN-OS 10.1 and earlier to ensure you push the correct policy rule and
certificate to the appropriate NGFWs.
• SSH Proxy.
To exclude matching traffic from decryption:
Set the Action to No Decrypt.

Apply a no-decryption profile to undecrypted traffic to block sessions with expired

certificates and untrusted issuers. Just because you don't decrypt the traffic does not
mean you should let just any undecrypted traffic on your network. Server certificate
checks help with this.

Decryption Administration 59 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 4 | (Optional) Select a Decryption Profile to perform additional checks on traffic that matches
the policy rule.
For example, set up certificate revocation status verification to ensure that server certificates
are valid or block sessions using unsupported protocols or ciphers.
To create a decryption profile, select Objects > Decryption Profile.

Although optional, always apply a decryption profile to decryption policy rules to

protect your network against encrypted threats. You can’t protect yourself against
threats you can’t see.

1. Create a decryption policy rule or open an existing rule to modify it.

2. Select Options and select a Decryption Profile to block and control various aspects of
the traffic matched to the rule.
The profile rule settings applied to matching traffic depends on the policy rule Action
(Decrypt or No Decrypt) and the policy rule Type (SSL Forward Proxy, SSL Inbound
Inspection, or SSH Proxy). This allows you to use the different decryption profiles with
different types of decryption policy rules that apply to different types of traffic and
users.
3. Click OK.

STEP 5 | Configure decryption logging (configure whether to log both successful and unsuccessful TLS
handshakes and configure decryption log forwarding).

STEP 6 | Click OK to save the rule.

STEP 7 | Commit your changes.

STEP 8 | Test your decryption configuration.

STEP 9 | Choose your next step...

• Configure SSL Forward Proxy.
• Configure SSL Inbound Inspection.
• Configure SSH Proxy.
• Create policy-based decryption exclusions for traffic you choose not to decrypt and add
sites that break decryption for technical reasons such as pinned certificates or mutual
authentication to the SSL decryption exclusion list.

Decryption Administration 60 ©2026 Palo Alto Networks, Inc.

Enable Decryption

Apply Granular Settings to Traffic Matching a

Decryption Policy Rule
Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Configure a decryption profile to define TLS handshake settings or session controls for traffic that
you decrypt or intentionally exclude from decryption. Decryption profiles enable granular control
over decrypted and nondecrypted sessions, so you can tailor decryption policy rules to meet
security and compliance requirements. After you apply a decryption profile to decryption policy
rules, the Next-Generation Firewall (NGFW) enforces the profile settings on traffic matching all
the criteria in the rule.
Each type of decryption profile has different settings to configure.
• SSL/TLS Decryption Profile (SSL Forward Proxy and SSL Inbound Inspection)—Use to specify
supported TLS versions and cipher suites, block sessions based on checks for unsupported
modes, session failure, and certificate validity, and configure additional settings.

Starting in PAN-OS 12.1.2, you can enable post-quantum cryptography (PQC)

algorithms for TLSv1.3 sessions.
• No-Decryption Profile—Use to verify server certificates and certificate issuer trustworthiness
for traffic that bypass decryption for compliance, legal, and nontechnical reasons and refuse
connections to servers with expired or untrusted certificates. This mitigates the risk of users
connecting to malicious or questionable. Apply these profiles only to decryption policy rules
with a no-decrypt action.

TLSv1.3 encrypts certificates during the TLS handshake, preventing the NGFW from
blocking TLSv1.3 sessions based on certificate information. As a result, applying a
no-decryption profile that only supports TLSv1.3 to a no-decryption policy rule has
no functional effect beyond the logging provided by the policy rule itself. For no-
decryption profiles that support other TLS versions including TLSv1.3, the NGFW only
enforces certificate checks for TLSv1.2 and earlier sessions but logs all sessions.
• SSH Proxy Profile—Use to block sessions based on checks for unsupported modes and session
failures.

If an NGFW is in FIPS-CC mode and managed by a Panorama™ management server in

standard mode, a decryption profile must be created locally on the NGFW. Decryption
profiles created on Panorama in standard mode contain references to the 3DES and RC4
encryption algorithms and the MD5 authentication algorithm that aren't supported and
cause pushes to managed NGFWs to fail.

Decryption Administration 61 ©2026 Palo Alto Networks, Inc.

Enable Decryption

Best Practices and Considerations for Decryption Profiles

• Always apply a decryption profile to decryption policy rules to protect your network against
sessions with expired certificates or untrusted issuers. You can’t protect yourself against
threats you can’t see.
• Use the strongest ciphers that you can. Weak protocols and weak algorithms contain known
vulnerabilities that attackers can exploit. Set Min Version to TLSv1.3 and Max Version to Max
to block weak protocols.
• Create separate decryption profiles when necessary to maximize security, and reuse profiles
where applicable:
• For example, suppose a key partner or contractor uses legacy systems with weak protocols
or algorithms. You can create a decryption profile that allows the weaker protocols or
algorithms and attach it to a decryption policy rule that applies only to the relevant traffic
(for example, the source IP address of the partner).
• If you need to allow client authentication, create a decryption profile with client
authentication settings, and apply it only to decryption policy rules for traffic that requires
client authentication.
Create separate profiles with protocol settings that match the capabilities of the servers
whose inbound or outbound traffic you are inspecting.
• Many mobile applications use pinned certificates. Because TLSv1.3 encrypts certificate
information, the NGFW can’t automatically add these applications to the SSL Decryption
Exclusion list. As a result, if you enable TLSv1.3, the NGFW may drop some mobile
applications. For these applications, you can either set the maximum TLS version to TLSv1.2 or
create a no-decryption policy rule specifically for this traffic.
• For SSL Forward Proxy traffic and traffic that you choose not to decrypt, configure both
certificate revocation list (CRL) and Online Certificate Status Revocation (OCSP) certificate
revocation checks.
Best Practices By Profile Type
SSL Forward Proxy
Block sessions with expired certificates
Block sessions with untrusted issuers
Block sessions with unsupported protocol versions
Block sessions with unsupported cipher suites
Block sessions with client authentication
SSL Inbound Inspection
Block sessions with unsupported versions
Block unsupported cipher suites
No Decryption
Block sessions with expired certificates
Block sessions with untrusted issuers
SSH Proxy

Decryption Administration 62 ©2026 Palo Alto Networks, Inc.

Enable Decryption

Block sessions with unsupported versions

Block sessions with unsupported algorithms
For more best practice insights, see Deploy SSL Decryption Using Best Practices.
• Strata Cloud Manager
• PAN-OS & Panorama

Apply Granular Settings to Traffic Matching a Decryption Policy

Rule (Strata Cloud Manager)
STEP 1 | Create a decryption profile.
1. Select Configuration > Security Services > Decryption.
2. Under Decryption Profiles, click Add Profile.
3. Enter a descriptive Name for the profile.
Names are case-sensitive and must be unique. You can use up to 31 characters, including
letters, numbers, spaces, hyphens, and underscores.
4. (Optional, Decryption Mirroring only) Enable mirroring of decrypted traffic.
Before enabling this feature, you must configure Decryption Port Mirroring.
1. Select an Ethernet Interface for mirroring decrypted traffic.
2. To mirror decrypted traffic only after Security policy rule enforcement, enable
Forwarded Only.
When enabled, the NGFW mirrors traffic after the Security policy rule lookup and just
before re-encryption. If a Security policy rule drops the traffic, the NGFW does not
mirror it. Enable this setting if you forward traffic to a threat detection device, such as
a data loss prevention (DLP) device or an intrusion prevention system (IPS).

Decryption Administration 63 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 2 | (Optional) Define TLS Handshake Settings for SSL Forward Proxy and SSL Inbound
Inspection.
1. For Protocol Min Version, select from SSLv3.0 and TLSv1.0–TLSv1.3.

Set the Protocol Min Version to TLSv1.3.

2. For Protocol Max Version, select from SSLv3.0, TLSv1.0–TLSv1.3, and Max.

Set the Protocol Max Version to Max to automatically support the newest TLS
version.
3. Configure Key Exchange Algorithms.
By default, RSA, DHE, and ECDHE are enabled.

You can enable post-quantum cryptography (PQC) algorithms for TLSv1.3

sessions. You must enable TLSv1.3 in the Handshake Settings.

• To configure traditional key exchange algorithms (RSA, DHE, and ECDHE), select
Classical, and then enable or disable algorithms as needed.

If you enable PQC algorithms and a client or server does not support PQC,
the NGFW negotiates a mutually supported classical algorithm.
• To configure post-quantum (PQ) key encapsulation mechanisms (KEM) for TLSv1.3
sessions:
1. Select Post-Quantum Cryptography (PQC), and then select PQC algorithm types:
• PQC Standard—Enables the NIST-standardized algorithm, ML-KEM (Module-
Lattice-Based Key-Encapsulation Mechanism)
• PQC Experimental—Enables nonstandardized algorithms, HQC, Bike, and
Frodo-KEM
2. For Preferred Session Settings, select the proxy sessions that prioritize PQC:
The NGFW negotiates a PQ KEM for the selected sessions when possible. The
NGFW translates between PQC and classical encryption, so it can secure one
proxy session with PQC even if the other side only supports classical algorithms.
• Post-Quantum SSL preferred for Client-side session—The firewall (acting as a
server) negotiates PQC algorithms if included in the client's cipher suite list
• Post-Quantum SSL preferred for Server-side session—The firewall (acting as a
client) places PQC algorithms first in its cipher suite list
4. Configure Encryption Algorithms.
Enable or disable algorithms as needed.
5. Configure Authentication Algorithms.

By default, MD5 is blocked.

Enable or disable algorithms as needed.

Decryption Administration 64 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 3 | (Optional) Define session controls for SSL Forward Proxy.

To configure the Failure Checks and Client Extensions settings and additional Server
Certificate Verification and Unsupported Mode Checks settings, click Advanced. An
Advanced SSL Forward Proxy Settings sidebar displays.

1. For Server Certificate Verification, enable Block sessions with expired certificates or
Block sessions with untrusted issuers.
You can configure the following Advanced settings:
• Block sessions with unknown certificate status
• Block sessions on certificate status check timeout
• Restrict certificate extensions
• Append certificate's CN value to SAN extension
• Automatically Fetch Intermediate Certificates
2. For Unsupported Mode Checks, enable Block sessions with unsupported versions or
Block sessions with unsupported cipher suites.
You can configure the Advanced setting: Block sessions with client authentication.
3. For Bypass Checks, enable Bypass Server Certificate Verification.

If you enable Bypass Server Certificate Verification, the NGFW does not
perform any other server certificate checks.
4. (Optional) To configure Failure Checks and Client Extension settings:
1. Select Advanced.
2. (Optional) For Failure Checks, enable Block downgrade on no resource.
3. (Optional) For Client Extension, enable Strip ALPN.
4. Save the Advanced SSL Forward Proxy Settings.

STEP 4 | (Optional) Define session controls for SSL Inbound Inspection.

1. For Unsupported Mode Checks, enable Block sessions with unsupported versions or
Block sessions with unsupported cipher suites.
2. For Failure Checks, enable Block sessions if resources not available or Block sessions if
HSM not available.

STEP 5 | (Optional) Define session controls for traffic you do not decrypt.
For Server Certificate Verification, select Block sessions with expired certificates or Block
sessions with untrusted issuers.

Apply no-decryption profiles to decryption policy rules that control traffic excluded
from decryption for compliance, legal, and nontechnical reasons. If a server breaks
decryption for technical reasons, add it to the Global Decryption Exclusion list
instead.

STEP 6 | Save the profile.

Decryption Administration 65 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 7 | Apply the profile to the appropriate decryption policy rules.

STEP 8 | Commit your changes.

Click Push Config > Push.

Apply Granular Settings to Traffic Matching a Decryption Policy

Rule (PAN-OS & Panorama)
STEP 1 | Create a decryption profile.
1. Select Objects > Decryption Profile, and then click Add.
2. Enter a descriptive Name for the profile.
Names are case-sensitive and must be unique. You can use up to 31 characters, including
letters, numbers, spaces, hyphens, and underscores.
3. (Optional, Panorama only) Configure profile sharing and inheritance settings.
• To share this profile across all virtual systems (vsys) on a multi-vsys NGFW or
Panorama device groups, select Shared.
• To prevent the override of profile settings in device groups that inherit the profile,
select Disable override.
By default, this setting is disabled; administrators can override settings in any device
group that inherits the profile.
4. (Optional, Decryption Mirroring only) Enable mirroring of decrypted traffic.
Before enabling this feature, you must configure Decryption Port Mirroring.
1. Select the Ethernet Interface for mirroring decrypted traffic.
2. To mirror decrypted traffic only after Security policy rule enforcement, enable
Forwarded Only.
When enabled, the NGFW mirrors traffic after the Security policy rule lookup and just
before re-encryption. If a Security policy rule drops the traffic, the NGFW does not
mirror it. Enable this setting if you forward traffic to a threat detection device, such as
a data loss prevention (DLP) device or an intrusion prevention system (IPS).

Decryption Administration 66 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 2 | (Optional) Define session controls and connection parameters for SSL/TLS traffic.
For descriptions of each setting, see Decryption Profile Settings.
1. To configure session controls:
1. Select SSL Decryption, and then select either SSL Forward Proxy or SSL Inbound
Inspection.
2. (Optional) For SSL Forward Proxy, enable settings for Server Certificate Verification,
Unsupported Mode Checks, Failure Checks, and Client Extension.

If you enable Bypass Server Certificate Verification, the NGFW does not
perform any other server certificate checks.
3. (Optional) For SSL Inbound Inspection, enable settings for Unsupported Mode Checks
and Failure Checks.
2. Configure minimum and maximum Protocol Versions.
1. Select SSL Protocol Settings.
2. For Min Version, select from SSLv3.0 and TLSv1.0–TLSv1.3.

Set the Min Version to TLSv1.3.

3. For Max Version, select from SSLv3.0, TLSv1.0–TLSv1.3, and Max.

Set the Max Version to Max to automatically support the newest TLS
version.
3. Configure Key Exchange Algorithms.
By default, RSA, DHE, and ECDHE are enabled.

Starting in PAN-OS 12.1.2, you can enable post-quantum cryptography (PQC)

algorithms for TLSv1.3 sessions. You must enable TLSv1.3 in the SSL Protocol
Settings.

• To configure classical key exchange algorithms (RSA, DHE, and ECDHE):

• (PAN-OS 11.2 and earlier) Enable or disable algorithms as needed.
• (PAN-OS 12.1.2 and later) Select Classical, and then enable or disable algorithms
as needed.

If you enable PQC algorithms and a client or server does not support PQC,
the NGFW negotiates a mutually supported classical algorithm.
• To configure post-quantum (PQ) key encapsulation mechanisms (KEM) for TLSv1.3
sessions:
1. Select Post-quantum Cryptography (PQC), and then select PQC algorithm types:
• PQC-Standard—Enables the NIST-standardized algorithm, ML-KEM (Module-
Lattice-Based Key-Encapsulation Mechanism)
• PQC-Experimental—Enables nonstandardized algorithms, HQC, Bike, and
Frodo-KEM

Decryption Administration 67 ©2026 Palo Alto Networks, Inc.

Enable Decryption

2. For Preferred Session Settings, select the proxy sessions that prioritize PQC:
The NGFW negotiates a PQ KEM for the selected sessions when possible. The
NGFW translates between PQC and classical encryption, so it can secure one
proxy session with PQC even if the other side only supports classical algorithms.
• Post-Quantum SSL preferred for Client-side session—The firewall (acting as a
server) negotiates PQC algorithms if included in the client's cipher suite list
• Post-Quantum SSL preferred for Server-side session—The firewall (acting as a
client) places PQC algorithms first in its cipher suite list
4. Configure Encryption Algorithms.
5. Configure Authentication Algorithms.
By default, MD5 is blocked.

STEP 3 | (Optional) Define session controls for traffic you do not decrypt.
1. Select No Decryption.
2. For Server Certificate Verification, enable Block sessions with expired certificates or
Block sessions with untrusted issuers.

STEP 4 | (Optional) Define session controls for SSH traffic.

1. Select SSH Proxy.
2. (Optional) For Unsupported Mode Checks, enable Block sessions with unsupported
versions or Block sessions with unsupported algorithms.
3. (Optional) For Failure Checks, enable Block sessions on SSH errors or Block sessions if
resources not available.

STEP 5 | Click OK.

STEP 6 | Apply the profile to the appropriate decryption policy rules.

STEP 7 | Commit your changes.

Decryption Administration 68 ©2026 Palo Alto Networks, Inc.

Enable Decryption

Fetch Certificates from Authority Information Access

(AIA) URL
Where Can I Use This? What Do I Need?

• Depending on the products you're using, you

need at least one of...
• For , an
For , no other requirements.

When a server presents an incomplete certificate chain, the Next-Generation Firewall (NGFW)
can't establish a chain of trust from the server certificate to a trusted root certificate authority
(CA). Typically, this causes the NGFW to drop the connection, preventing inspection of the
SSL/TLS traffic (unless you allow sessions with untrusted issuers). Browsers also block these
connections and display invalid certificate or insecure connection warnings.
To address this issue, you could manually repair incomplete certificate chains or bypass
decryption for the affected sites. However, manual repair is time-consuming, and bypassing
decryption leaves potentially malicious traffic uninspected. For SSL Forward Proxy sessions,
you can enable automatic fetching of missing intermediate certificates when server certificates
contain the Authority Information Access (AIA) extension. The AIA extension provides the URL
from which the NGFW retrieves the issuing CA's certificate to complete the certificate chain.
Automatic retrieval prevents service disruption, eliminates the need to bypass decryption, and
lightens your operational load.
How Certificate Fetching Using AIA Works
The following process occurs if the server certificate the NGFW received during the failed TLS
handshake contains the AIA extension:
1. Check the Intermediate Certificate Cache
The NGFW checks the cache for the missing intermediate certificates. If found, the NGFW
verifies:
• The Subject Name (SN) of the cached certificates matches the issuer name of the server
certificate
• The cached certificates haven't expired
• The certificate chain is properly signed
• The certificate chain leads to a trusted root CA
If these criteria are met, the TLS handshake proceeds.

Decryption Administration 69 ©2026 Palo Alto Networks, Inc.

Enable Decryption

2. Fetch Certificates from the AIA URL

If the Intermediate Certificate Cache doesn't contain the intermediate certificates, the NGFW
downloads the missing intermediate certificates from the AIA URL.
• The NGFW verifies the newly fetched intermediate certificate as in the previous step. If the
certificate isn't signed by a trusted root CA, the NGFW recursively fetches up to two more
levels of intermediate certificates (maximum fetches is three).
• The NGFW verifies the last fetched certificate is signed by a trusted root CA.
3. Add to Intermediate Certificate Cache
The NGFW adds fetched intermediate certificates to the cache, so that subsequent TLS
sessions with the same server can use them.
The NGFW stores fetched certificates in the cache for up to one week, depending on certificate
expiration dates. If a certificate expires in less than a week, the cache entry expires when the
certificate does. For certificates that have already expired, the cache entry lasts for one day.

The server remains untrusted, and the connection is handled according to your policy
rules, in the following cases:
• The certificate doesn't contain the AIA extension.
• The connection to the AIA URL times out.
• The AIA URL returns an invalid response.
• The certificate fetched from the AIA URL fails to verify the server certificate (signature
verification fails).

To view and manage cached intermediate certificates, go to the Cached Intermediate Certificates
tab in your management interface.
To monitor the status of AIA retrieval, review the Server Certificate Status field in the decryption
logs. After successful certificate fetches, the status displays Valid by OCSP/CRL. You can
use this information to troubleshoot SSL/TLS connections with incomplete certificate chains and
verify if the feature works correctly.
STEP 1 | Configure a service route for CRL, OCSP, Intermediate Certificates (formerly CRL Status).
This feature shares the same service route used for CRL and OSCP revocation status checking.

STEP 2 | In your SSL Forward Proxy decryption profiles, enable Automatically Fetch Intermediate
Certificates.

STEP 3 | Apply the decryption profiles to the decryption policy rules that manage the affected traffic.

STEP 4 | Commit your changes.

Decryption Administration 70 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 5 | Verify that automatic retrieval using AIA works.

1. Access a website for which the server certificate has been incomplete.

The initial session will fail, which initiates the fetching process.

2. Start a new session by refreshing the page or accessing the website in a new window.
3. Confirm that the browser no longer displays a warning and that you can access the site
without issues.
4. Review the decryption logs for the first session and a subsequent session.
• Server Certificate Status for the first session should note that fetching is in progress.
• Server Certificate Status for a subsequent session should display Valid by OCSP/CRL.

Decryption Administration 71 ©2026 Palo Alto Networks, Inc.

Enable Decryption

Configure SSL Forward Proxy

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

To enable SSL Forward Proxy decryption, set up the certificates required to establish the Next-
Generation Firewall (NGFW) as a trusted third party (proxy) to the session between the client
and the server. You can use certificates signed by an enterprise certificate authority (CA) or self-
signed certificates generated on the NGFW as Forward Trust certificates to authenticate the SSL/
TLS session with the client.
• (Best Practice) Enterprise CA-signed Certificates—An enterprise CA can issue a signing
certificate that an NGFW uses to sign the certificates for sites requiring SSL/TLS decryption.
When the NGFW trusts the CA that signed the certificate of the destination server, it can send
a CA-signed copy of the destination server certificate to the client.
This is a best practice because it streamlines the rollout process. Network devices typically
trust the enterprise CA already (it is usually installed in the devices’ CA trust storage), so you
don’t need to deploy the certificate on endpoints.
• Self-signed Certificates—An NGFW can act as a CA and generate self-signed certificates that
it uses to sign the certificates for sites requiring SSL/TLS decryption. The NGFW signs a copy
of the server certificate to present to the client and establish an SSL session. This method
requires installation of the self-signed certificates on all network devices, so that those devices
recognize the self-signed certificates. Self-signed certificates are better for small deployments
and proof of concept (PoC) trials because of the need to install certificates on all devices.
Additionally, set up a Forward Untrust certificate for the NGFW to present to clients when the
server certificate is signed by a CA that the NGFW doesn't trust. This ensures that clients receive
a certificate warning when attempting to access sites with untrusted certificates.

Generate separate subordinate Forward Trust CA certificates for each NGFW, regardless
of if you use enterprise-CA signed or self-signed certificates. This practice offers several
benefits:
• Enables you to revoke one certificate when you decommission a device (or device pair)
without affecting the rest of the deployment.
• Reduces the impact in any situation requiring revocation of a certificate.
• Improves troubleshooting because the CA error message the user sees includes
information about the NGFW the traffic is traversing. If you use the same Forward
Trust CA, you lose the granularity of that information.

After setting up Forward Trust and Forward Untrust certificates, create a decryption policy rule
to define the traffic you want to decrypt. Next, create a decryption profile to apply additional
SSL/TLS controls and checks to the defined traffic. Traffic that matches the rule is converted to

Decryption Administration 72 ©2026 Palo Alto Networks, Inc.

Enable Decryption

cleartext. The NGFW blocks and restricts traffic based on the decryption profile and Security
policy rules, then re-encrypts the traffic as it exits the NGFW.

When you configure SSL Forward Proxy, the proxied traffic does not support DSCP code
points or QoS.

• Strata Cloud Manager

• PAN-OS & Panorama

Configure SSL Forward Proxy (Strata Cloud Manager)

STEP 1 | Verify that the appropriate interfaces are configured as either virtual wire, Layer 2, or Layer
3 interfaces.
To view the configured interfaces, select Configuration > NGFW and Prisma Access > Device
Settings > Interfaces.

Decryption Administration 73 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 2 | Configure the Forward Trust certificate that the NGFW presents to clients when a trusted
CA has signed the server certificate.
(Best Practice) Use an enterprise CA-signed certificate as the Forward Trust certificate.
1. Generate a certificate signing request (CSR) for the enterprise CA to sign and validate:
1. Select Configuration > NGFW and Prisma Access > Objects > Certificate Management.
2. Click Generate to add a custom certificate.
3. Enter a Certificate Name. Use a unique name for each NGFW.
4. For Signed By, select External Authority (CSR).
5. For Certificate Use For, select Forward Trust Certificate.
6. Specify Cryptographic Settings: Algorithm, Number of Bits, Digest, and Expiration.
7. (Optional) Add Certificate Attributes, such as Country or Department, to identify the
NGFW.
8. (Optional) Select an OCSP Responder.
9. Save the CSR.
The pending certificate displays under Custom Certificates.
2. Export the CSR:
1. Under Custom Certificates, select the pending certificate, and then click Export
Certificate.
2. Click Export to download and save the certificate file.
3. Select a Format for the certificate, and Save the setting to download the certificate file.
4. Provide the certificate file to your enterprise CA. When you receive the enterprise CA-
signed certificate, save it onto your system.
3. Import the enterprise CA-signed certificate onto Strata Cloud Manager.
An Import Certificate dialog appears.
1. Enter the pending Certificate Name exactly.

The Certificate Name that you enter must exactly match the pending certificate
name for the pending certificate to be validated.
2. Select the signed Certificate File that you received from your enterprise CA.
3. (Optional) Browse and select a Key File.
4. (Optional) Enter a Passphrase, then Confirm Passphrase
5. Click Save to import the signed certificate.
4. Select the validated certificate and for Certificate Use For, select Forward Trust Certificate.
5. Click Update to confirm your changes.
Use a self-signed certificate as the Forward Trust certificate:
1. Create a self-signed root CA certificate.
1. Select Configuration > NGFW and Prisma Access > Objects > Certificate Management.
2. Generate a certificate.

Decryption Administration 74 ©2026 Palo Alto Networks, Inc.

Enable Decryption

3. Enter a unique Certificate Name.

4. Enter a Common Name. This should be the FQDN (recommended) or IP address of the
interface where you will configure the service that will use this certificate.
5. Leave Signed By blank.
6. For Certificate Use For, select Forward Trust Certificate.
7. Specify Cryptographic Settings: Algorithm, Number of Bits, Digest, and Expiration.
8. Leave the OCSP Responder field blank. Revocation status verification doesn’t apply to
root CA certificates.
9. (Optional) Add Certificate Attributes, such as Country or Department, to identify the
NGFW.
[Link] Save to generate the certificate.
2. Designate the certificate as a trusted root CA.
1. Click the certificate in the Custom Certificates list (Configuration > NGFW and Prisma
Access > Objects > Certificate Management).
Certificate settings and details appear.
2. For Certificate Use for, select Trusted Root CA.
3. Save the certificate.
3. Generate new subordinate CA certificates for each NGFW:
1. Select Configuration > NGFW and Prisma Access > Objects > Certificate Management.
2. Click Generate.
3. Enter a Certificate Name.
4. Enter a Common Name. This should be the FQDN (recommended) or IP address that
appears in the certificate.
5. For Signed By, select the self-signed root CA certificate that you created.
6. For Certificate Use For, select Forward Trust Certificate.
7. Select Certificate Authority to enable the NGFW to issue the certificate. This creates a
certificate authority (CA) that is imported to client browsers, so clients trust the NGFW
as a CA.
8. Specify Cryptographic Settings: Algorithm, Number of Bits, Digest, and Expiration.
9. (Optional) Add Certificate Attributes, such as Country or Department, to further identify
the NGFW.
[Link] Save to generate the certificate.
[Link] this procedure for each NGFW.

Decryption Administration 75 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 3 | Distribute the Forward Trust certificate to client system certificate stores.

Skip this step if you're using an enterprise-CA signed certificate as the Forward Trust
certificate and the client systems already have the enterprise CA installed in the
local trusted root CA list. (The client systems trust the subordinate CA certificates you
generate on the NGFW because the enterprise trusted root CA has signed them.)

If you don’t install the Forward Trust certificate on client systems, users see certificate
warnings for each SSL site they visit.
On an NGFW configured as a GlobalProtect portal:

This option is supported with Windows and Mac client OS versions, and requires
GlobalProtect app 3.0.0 or later to be installed on the client systems.

1. Select Network > GlobalProtect > Portals and then select an existing portal
configuration or Add a new one.
2. Select Agent and then select an existing agent configuration or Add a new one.
3. Add the self-signed trusted root CA certificate to the Trusted Root CA section. After
GlobalProtect distributes the trusted root CA certificate to client systems, the client
systems trust the NGFW's subordinate CA certificates because the clients trust the
NGFW's root CA certificate.
4. Install in Local Root Certificate Store so that the GlobalProtect portal automatically
distributes the certificate and installs it in the certificate store on GlobalProtect client
systems.
5. Click OK twice.
Without GlobalProtect:
Export the trusted root CA certificate so that you can import it into client systems. Highlight
the certificate and click Export at the bottom of the window. Choose the PEM format.

Don’t select Export private key. The private key should remain on the NGFW and not
be exported to client systems.

Import the trusted root CA certificate into the browser Trusted Root CA list on the client
systems for the clients to trust it. When importing into the client browser, ensure that you
add the certificate to the Trusted Root Certification Authorities certificate store. On Windows
systems, the default import location is the Personal certificate store. You can also simplify this
process by using a centralized deployment option, such as an Active Directory Group Policy
Object (GPO).

Decryption Administration 76 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 4 | Configure the Forward Untrust certificate (use the same Forward Untrust certificate for each
NGFW).
1. Select Configuration > NGFW and Prisma Access > Objects > Certificate Management.
2. Generate a certificate.
3. Enter a unique Certificate Name.
4. Enter a Common Name. This should be the FQDN (recommended) or IP address that
appears in the certificate.
5. Leave Signed By blank.
6. For Certificate Use For, select Forward Untrust Certificate.
7. Specify Cryptographic Settings: Algorithm, Number of Bits, Digest, and Expiration.
8. (Optional) Add Certificate Attributes, such as Country or Department, to further identify
the NGFW.
9. (Optional) Select an OCSP Responder.
10. Click Save.

Don't export the Forward Untrust certificate to the certificate trust lists of your
network devices. Don't install the Forward Untrust certificate on client systems.
Installing the Untrust certificate in the Trust List results in devices trusting
websites that the NGFW doesn't trust. In addition, users won’t see certificate
warnings for untrusted sites, so they may access those sites, which could expose
your network to threats.

STEP 5 | (Optional) Configure the key size for the SSL Forward Proxy server certificates that the
NGFW presents to clients.
By default, the NGFW determines the key size to use based on the key size of the destination
server certificate.

STEP 6 | Create a decryption policy rule to define criteria that traffic must match for SSL Forward
Proxy decryption.
• In the Action and Advanced Inspection section, for Action, select Decrypt.
• For decryption Type, select SSL Forward Proxy.
• (Optional but a best practice) Configure or select a Decryption Profile to block and control
various aspects of matching traffic.
For example, create a decryption profile or select one that performs certificate checks and
blocks weak cipher suites and protocols from allowing questionable traffic on your network.
• Save the decryption policy rule.

STEP 7 | To start enforcing the rule, select Push Config > Push.

STEP 8 | Choose your next step:

• Enable users to opt out of SSL decryption.
• Configure decryption exclusions to disable decryption for certain types of traffic.
• (Advanced WildFire subscriptions only) Forward decrypted SSL traffic for WildFire analysis.

Decryption Administration 77 ©2026 Palo Alto Networks, Inc.

Enable Decryption

Configure SSL Forward Proxy (PAN-OS & Panorama)

STEP 1 | Confirm that the appropriate interfaces are configured as either virtual wire, Layer 2, or
Layer 3 interfaces.
Select Network > Interfaces > Ethernet, and then check the Interface Type column for Virtual
Wire, Layer 2, or Layer 3. Select an Interface to modify its configuration.

Decryption Administration 78 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 2 | Configure the Forward Trust certificate that the NGFW presents to clients after a trusted CA
signs the server certificate.
• (Best Practice) Use an enterprise CA-signed certificate as the Forward Trust certificate:
1. Create a certificate signing request (CSR) for the enterprise CA:
1. Select Device > Certificate Management > Certificates > Custom Certificates (Device
Certificates in PAN-OS 11.2 and earlier), and then click Generate.
2. Enter a unique Certificate Name.
3. Enter a Common Name. This should be the IP address or FQDN that appears in the
certificate. Avoid using spaces in this field.
4. For Signed By, select External Authority (CSR).
5. (Optional) Add Certificate Attributes, such as Country or Department, to identify
the NGFW.
6. To save the CSR, click Generate.
The Custom Certificates list displays the CSR with a Status of pending.
2. Export the CSR.
1. From the Custom Certificates list, select the pending certificate, and then click Export
Certificate.
The CSR downloads.
2. Save the CSR.
3. Submit the certificate request to the enterprise CA.
After receiving the signed certificate, save it to your system.
4. (Required for Clients Running Windows or Windows Server) Generate a subordinate CA
certificate.
1. Submit a certificate request that uses the Subordinate Certification Authority
certificate template based on the CSR that you previously exported.
2. Download the certificate chain.

Decryption Administration 79 ©2026 Palo Alto Networks, Inc.

Enable Decryption

Configure Missing Subordinate Certificate Authority Template

The Subordinate Certificate Authority template may be unavailable for reasons
such as a failed migration or missing permissions. Try the following procedure to
configure the missing template:
1. Launch the Certificate Manager tool. From the Command Line, PowerShell, or
Run, enter [Link].

2. Under the Certificate Authority (Local) header, right-click Certificate

Templates. Then, click New > Certificate Template to Issue.

Decryption Administration 80 ©2026 Palo Alto Networks, Inc.

Enable Decryption

5. Import the enterprise CA-signed certificate and subordinate CA certificate (if applicable)
onto the NGFW.
1. Select Device > Certificate Management > Certificates > Custom Certificates, and
then click Import.
An Import Certificate dialog appears.
2. Enter the Certificate Name as it appears in the CSR. For successful validation, the
name must match the pending certificate name exactly.
3. Browse for the Certificate File.
4. Click OK.
The Custom Certificates tab displays the certificate with a Status of valid and the
Key and CA check boxes selected.
5. Repeat the import steps for the subordinate CA certificate.
6. Designate a Forward Trust Certificate.
• If you don't have a subordinate CA certificate:
1. From the Custom Certificates list, select the enterprise CA-signed certificate.
The Certificate information dialog opens.
2. Select the Forward Trust Certificate option.
3. Click OK.
• (Windows or Windows Server users) Mark only the subordinate CA certificate as the
Forward Trust certificate , and then click OK.
• Use a self-signed certificate as the Forward Trust certificate:
1. Generate a self-signed root CA certificate.
The certificate is automatically saved to the Custom Certificates (Device Certificates in
PAN-OS 11.2 and earlier) list.
2. Designate the certificate as the trusted root CA certificate.
1. Select the self-signed certificate from the Custom Certificates list (Device >
Certificate Management > Certificates > Custom Certificates).
The Certificate information dialog opens.
2. Select the Trusted Root CA option.
3. Click OK.
3. Generate a new subordinate CA certificate for each NGFW:
1. Select Device > Certificate Management > Certificates > Custom Certificates, and
then click Generate.
2. Enter a unique Certificate Name.
3. Enter a Common Name. This should be the IP address or FQDN that appears in the
certificate. Avoid using spaces in this field.
4. For Signed By, select the self-signed root CA certificate.
5. Select the Certificate Authority option.

Decryption Administration 81 ©2026 Palo Alto Networks, Inc.

Enable Decryption

This option enables the NGFW to issue the certificate.

6. Generate the certificate.
7. Repeat for each NGFW.

STEP 3 | Distribute the Forward Trust certificate to client system certificate stores.

SKIP THIS STEP if you're using an enterprise-CA signed certificate as the Forward
Trust certificate and the client systems already have the enterprise CA installed in
their local trusted root CA list. (The client systems trust the subordinate CA certificates
generated on the NGFW because the enterprise trusted root CA has signed them.)

If you don't install the Forward Trust certificate on client systems, users see certificate
warnings for each SSL site they visit.
• On an NGFW configured as a GlobalProtect portal:

This option is supported with Windows and Mac client OS versions, and requires
installation of GlobalProtect app 3.0.0 or later on the client systems.

1. Select Network > GlobalProtect > Portals, and then select an existing portal
configuration or Add a new one.
2. Select Agent, and then select an existing agent configuration or Add a new one.
3. Add the self-signed trusted root CA certificate to the Trusted Root CA section.
After GlobalProtect distributes the trusted root CA certificate to client systems, the
client systems trust the NGFW's subordinate CA certificates because the clients trust the
root CA certificate.
4. Install in Local Root Certificate Store to enable the GlobalProtect portal to automatically
distribute and install the certificate in the certificate store on GlobalProtect client
systems.
5. Click OK twice.
• Without GlobalProtect:
1. Export the NGFW trusted root CA certificate so you can import it to client systems.
Highlight the certificate, and then Export it in PEM format.

Don't select the Export private key checkbox. The private key should remain on
the NGFW and not be exported to client systems.
2. Import the trusted root CA certificate into the browser Trusted Root CA list on the client
systems.
When importing, ensure that you add the certificate to the Trusted Root Certification
Authorities certificate store. On Windows systems, the default import location is the
Personal certificate store. You can also simplify this process by using a centralized
deployment option, such as an Active Directory Group Policy Object (GPO).

Decryption Administration 82 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 4 | Configure the Forward Untrust certificate.

Use the same Forward Untrust certificate for each NGFW. Clients receive a certificate warning
when attempting to access sites with untrusted certificates.

• Don't export the Forward Untrust certificate to the certificate trust lists of your
network devices.
• Don't install the Forward Untrust certificate on client systems. Installing the
Untrust certificate in the Trust List results in devices trusting websites that the
NGFW doesn't trust. In addition, users won’t see certificate warnings for untrusted
sites, so they may access those sites, which could expose your network to threats.

1. Select Device > Certificate Management > Certificates > Custom Certificates, and then
click Generate.
2. Enter a Certificate Name.
3. Enter a Common Name. Leave Signed By blank.
4. Select the Certificate Authority option.
5. Generate the certificate.
6. Designate the certificate as the Forward Untrust certificate.
1. Select Device > Certificate Management > Certificates > Custom Certificates, and
then select the Forward Untrust certificate.
The Certificate information dialog opens.
2. Select the Forward Untrust Certificate option.
3. Click OK.

STEP 5 | (Optional) Configure the key size for the SSL Forward Proxy server certificates that the
NGFW presents to clients.
By default, the NGFW determines the key size to use based on the key size of the destination
server certificate.

STEP 6 | Create a decryption policy rule for SSL Forward Proxy.

1. Select Policies > Decryption, add or modify an existing rule, and define traffic to be
decrypted.
2. Select Options and:
• For Action, select Decrypt.
• For Type, select SSL Forward Proxy.
• (Optional but a best practice) Configure or select an existing Decryption Profile to
block and control various aspects of the decrypted traffic.
For example, create a decryption profile or select one that performs certificate checks
and blocks weak cipher suites and protocols from allowing questionable traffic on
your network.
3. Click OK.

STEP 7 | Commit your changes.

Decryption Administration 83 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 8 | Choose your next step:

• Enable users to opt out of SSL decryption.
• Configure decryption exclusions to disable decryption for certain types of traffic.
• (Advanced WildFire® subscriptions only) Forward decrypted SSL traffic for WildFire
analysis.

Decryption Administration 84 ©2026 Palo Alto Networks, Inc.

Enable Decryption

Configure SSL Inbound Inspection

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

You can decrypt and inspect SSL/TLS traffic destined for internal servers. SSL Inbound Inspection
provides visibility into network activity, enabling effective monitoring and handling of potentially
risky traffic that isn't outright blocked. Inbound inspection requires the certificate and private
key of each server you want to protect. To inspect SSL/TLS traffic to internal servers, install the
certificates and private keys on the Next-Generation Firewall (NGFW), and create decryption
policy rules for SSL Inbound Inspection.

If you store the certificates and private keys on a hardware security module (HSM),
you don't need to install them on the NGFW.

You can associate up to 12 certificates with a single decryption policy rule. Support for multiple
certificates enables you to update server certificates without disrupting service and protect
internal servers hosting various domains, each with a unique certificate.
To strengthen security, configure a decryption profile that blocks sessions using insecure protocol
versions and cipher suites. Next, apply the profile to the decryption policy rules for SSL Inbound
Inspection. The NGFW enforces the actions defined in the decryption profile and additional
profiles applied to the rules. These may include Antivirus, Vulnerability Protection, Anti-Spyware,
URL Filtering, and File Blocking profiles.
As a best practice, forward decrypted SSL traffic to the Advanced WildFire® cloud for further
analysis and signature generation.

When you configure SSL Inbound Inspection, the proxied traffic does not support DSCP
code points or QoS.

SSL Inbound Inspection does not support Authentication Portal redirect. To use
Authentication Portal redirect and decryption, configure SSL Forward Proxy.

• Strata Cloud Manager

• PAN-OS & Panorama

Configure SSL Inbound Inspection (Strata Cloud Manager)

Decryption Administration 85 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 1 | Verify that the appropriate interfaces are configured as either virtual wire, Layer 2, or Layer
3 interfaces.

You can't use a tap mode interface for SSL Inbound Inspection.

To view the configured interfaces, select Configuration > NGFW and Prisma Access > Device
Settings > Interfaces. You can select an interface to modify its configuration, including the
interface type.

STEP 2 | Verify installation of the certificate for the destination server.

To view installed certificates, log in to Strata Cloud Manager, and then select Configuration >
NGFW and Prisma Access > Objects > Certificate Management.

The TLS versions that your web server supports determine how you should install the
server certificate and key. We recommend uploading a certificate chain (a single file)
if your end-entity (leaf) certificate is signed by one or more intermediate certificates
and your web server supports TLSv1.2 and either RSA or PFS key exchange algorithms.
Uploading the chain avoids client-side server certificate authentication issues.
Arrange the certificates in the file as follows:
1. End-entity (leaf) certificate
2. Intermediate certificates (in issuing order)
3. (Optional) Root certificate
You can upload the server certificate and private key alone to Strata Cloud Manager
when the leaf certificate is signed by intermediate certificates, if your web server
supports TLSv1.3 connections and the certificate chain has been installed on the
server. SSL Inbound Inspection discusses each case in detail.

To import the server certificate onto Strata Cloud Manager:

1. Select Configuration > NGFW and Prisma Access > Objects > Certificate Management,
and then Import a Custom Certificate.
2. Enter a descriptive Certificate Name.
3. Browse for and select the Certificate File.
4. Save the certificate.

Decryption Administration 86 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 3 | Create a decryption policy rule to define the traffic that the NGFW decrypts.
1. Select Configuration > NGFW and Prisma Access > Security Services > Decryption, and
then Add Rule or select an existing rule.
2. Under the Action and Advanced Inspection section, configure the following settings:
• For Action, select Decrypt.
• For Type, select SSL Inbound Inspection.
• Add up to 12 Certificates for the internal server you want to protect.

To update the certificate for a protected internal server without incurring

downtime, follow these steps:
1. Renew or obtain a new server certificate before the current one expires or
otherwise becomes invalid.
2. Import the new certificate and private key onto your NGFW.
3. Add the new certificate to your SSL Inbound Inspection policy rule.
This must be done while a different certificate is active on the web server,
so that a valid certificate in the policy rule always matches the certificate
presented by the server.
4. Install the new certificate on your web server, and then verify that it was
properly installed.
Installation of the new certificate doesn't impact existing connections. The
NGFW verifies that the certificate in the Server Hello message matches the
certificate in your decryption policy rule. If there isn't a match, the session
ends, and the corresponding decryption log entry reports the session-end
reason as a certificate mismatch between the firewall and server. To view
the server certificates used in all inbound inspection sessions, select the Log
Successful TLS handshakes and Log Unsuccessful TLS handshakes options
under the Log Settings section of a decryption policy rule.
• (Best Practice) Select or create a Decryption Profile that blocks insecure protocol
versions and cipher suites.
To create a best practice decryption profile for SSL Inbound Inspection, configure the
options described in SSL Inbound Inspection Decryption Profile.

Create separate profiles for servers with different security capabilities.

For example, if a group of servers supports only RSA, in the SSL Protocol
Settings of the decryption profile, select only RSA for the key exchange
algorithm. Likewise, for servers that support only PFS, set the SSL Protocol
Settings to only support PFS.
Configure the SSL Protocol Settings for the highest level of security that the
server supports, but check performance to ensure that the NGFW can handle
the higher processing load that higher security protocols and algorithms
require.
3. Save your changes.

Decryption Administration 87 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 4 | (Advanced WildFire subscriptions only) Forward decrypted SSL traffic to the Advanced
WildFire cloud for analysis.

STEP 5 | (PAN-OS 11.2 & later, HSM deployments only) Activate TLSv1.3 support for SSL Inbound
Inspection with an HSM.
Use the set ssl inbound-inspection tls1.3-with-hsm enable yes CLI
command.

STEP 6 | Commit your changes.

Select Push Config > Push.

STEP 7 | Choose your next step:

• Enable users to opt out of SSL decryption.
• Configure decryption exclusions for traffic that you don’t want to decrypt.

Configure SSL Inbound Inspection (PAN-OS & Panorama)

STEP 1 | Verify that the appropriate interfaces are configured as either virtual wire, Layer 2, or Layer
3 interfaces.

You can't use a tap mode interface for SSL Inbound Inspection.

To view the configured interfaces, select Network > Interfaces > Ethernet. You can select an
interface to modify its configuration, including the interface type.

Decryption Administration 88 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 2 | Verify installation of the certificate for the destination server.

To view installed certificates, log in to the NGFW, Prisma Access, or a management interface,
select Device > Certificate Management > Certificates > Device Certificates.

The TLS versions that your web server supports determine how you should install the
server certificate and key. We recommend uploading a certificate chain (a single file)
if your end-entity (leaf) certificate is signed by one or more intermediate certificates
and your web server supports TLSv1.2 and either RSA or PFS key exchange algorithms.
Uploading the chain avoids client-side server certificate authentication issues.
Arrange the certificates in the file as follows:
1. End-entity (leaf) certificate
2. Intermediate certificates (in issuing order)
3. (Optional) Root certificate
You can upload the server certificate and private key alone when the leaf certificate is
signed by intermediate certificates, if your web server supports TLSv1.3 connections
and the certificate chain has been installed on the server. SSL Inbound Inspection
discusses each case in detail.

To import the targeted server certificate onto the NGFW:

1. Select Device > Certificate Management > Device Certificates, and then Import a
certificate.
2. Enter a descriptive Certificate Name.
3. Browse for and select the Certificate File.
4. Click OK to save your changes.

Decryption Administration 89 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 3 | Create a decryption policy rule to define the traffic that the firewall decrypts.
1. Select Policies > Decryption, and then Add a new rule or modify an existing rule.
2. Select Options and configure the following:
• For Action, select Decrypt.
• For Type, select SSL Inbound Inspection.
• Add up to 12 Certificates for the internal server you want to protect.

To update the certificate for a protected internal server without incurring

downtime, follow these steps:
1. Renew or obtain a new server certificate before the current one expires or
otherwise becomes invalid.
2. Import the new certificate and private key onto your NGFW.
3. Add the new certificate to your SSL Inbound Inspection decryption policy
rule.
This must be done while a different certificate is active on the web server,
so that a valid certificate in the policy rule always matches the certificate
presented by the server.
4. Install the new certificate on your web server, and then verify that it was
properly installed.
Installation of the new certificate doesn't impact existing connections. The
NGFW verifies that the certificate in the Server Hello message matches the
certificate in your decryption policy rule. If there isn't a match, the session
ends, and the corresponding decryption log entry reports the session-end
reason as a certificate mismatch between the firewall and server. To view
the server certificates used in all inbound inspection sessions, select Log
Successful SSL Handshake under Log Settings (Policies > Decryption >
Options).
™
(Panorama ) Support for multiple certificates in SSL Inbound Inspection
policy rules isn't available on PAN-OS versions earlier than PAN-OS 10.2.
If you push an SSL Inbound Inspection policy rule with multiple certificates
from a Panorama management server running PAN-OS 11.1 to an NGFW
running older software, the policy rule on the managed NGFW inherits only
the first certificate from the alphabetically sorted list of certificates.
Before pushing your decryption policy rule from Panorama, we recommend
setting up different templates or device groups for NGFWs running PAN-OS
10.1 and earlier to ensure you push the correct policy rule and certificate to
the appropriate NGFWs.
• (Best Practice) Select or create a Decryption Profile that blocks insecure protocol
versions and cipher suites.
To create a best practice decryption profile for SSL Inbound Inspection, configure the
options described in SSL Inbound Inspection Decryption Profile.

Decryption Administration 90 ©2026 Palo Alto Networks, Inc.

Enable Decryption

Create separate profiles for servers with different security capabilities.

For example, if a group of servers supports only RSA, in the SSL Protocol
Settings of the decryption profile, select only RSA for the key exchange
algorithm. Likewise, for servers that support only PFS, set the SSL Protocol
Settings to only support PFS.
Configure the SSL Protocol Settings for the highest level of security that the
server supports, but check performance to ensure that the NGFW can handle
the higher processing load that higher security protocols and algorithms
require.
3. Click OK to save your changes.

STEP 4 | (Advanced WildFire subscriptions only) Forward decrypted SSL traffic to the Advanced
WildFire cloud for analysis.

STEP 5 | Commit your changes.

STEP 6 | (PAN-OS 11.2, HSM deployments only) Activate TLSv1.3 support for HSM integration with
SSL Inbound Inspection.
Use the set ssl inbound-inspection tls1.3-with-hsm enable yes CLI
command.

STEP 7 | Choose your next step:

• Enable users to opt out of SSL decryption.
• Configure decryption exclusions for traffic that you don’t want to decrypt.

Decryption Administration 91 ©2026 Palo Alto Networks, Inc.

Enable Decryption

Configure SSH Proxy

Where Can I Use This? What Do I Need?

• Prisma Access (Managed by Panorama) No requirements.

• NGFW (Managed by PAN-OS or
Panorama)

Configuring SSH Proxy does not require certificates, and the key used to decrypt SSH sessions
is automatically generated on the Next-Generation Firewall (NGFW) during boot up. The NGFW
blocks or restricts SSH traffic based on your decryption policy rules and decryption profiles.
Traffic is re-encrypted as it exits the NGFW.

Next-Generation Firewalls can’t decrypt and inspect traffic within an SSH tunnel.

When you configure SSH Proxy, the proxied traffic does not support DSCP code points or
QoS.

STEP 1 | Ensure that the appropriate interfaces are configured as either virtual wire, Layer 2, or Layer
3 interfaces.
Decryption can only be performed on virtual wire, Layer 2, or Layer 3 interfaces. To view
configured interfaces, select Network > Interfaces > Ethernet
The Interface Type column displays if an interface is configured as a Virtual Wire, Layer 2, or
Layer 3 interface. You can select an interface to modify its configuration, including its type.

STEP 2 | Create a decryption policy rule or modify an existing rule that decrypts SSH traffic.

Include a decryption profile with each decryption policy rule to prevent weak,
vulnerable protocols and algorithms from allowing questionable traffic on your
network.

After defining the match criteria for the rule, select Options and configure the following
settings:
1. For Action, select Decrypt.
2. For Type, select SSH Proxy.
3. (Optional but a best practice) Configure or select an existing Decryption Profile to block
and control various aspects of the decrypted traffic (for example, you can use a profile to
terminate sessions with unsupported SSH versions and unsupported algorithms).
4. Click OK to save the rule.

Decryption Administration 92 ©2026 Palo Alto Networks, Inc.

Enable Decryption

STEP 3 | (Optional) Block all SSH tunnel traffic.

1. Configure a Security policy rule for the ssh-tunnel application with the Action set to
Deny.
2. Configure a Security policy rule that allows traffic from the ssh application.

STEP 4 | Commit your changes.

STEP 5 | (Optional) Create decryption exclusions to disable decryption for certain types of traffic.

Configure SSH Proxy (PAN-OS)

STEP 1 | Ensure that the appropriate interfaces are configured as either virtual wire, Layer 2, or Layer
3 interfaces.
Decryption can only be performed on virtual wire, Layer 2, or Layer 3 interfaces. To view
configured interfaces, select Network > Interfaces > Ethernet
The Interface Type column displays if an interface is configured as a Virtual Wire, Layer 2, or
Layer 3 interface. You can select an interface to modify its configuration, including its type.

STEP 2 | Create a decryption policy rule or modify an existing rule that decrypts SSH traffic.

Include a decryption profile with each decryption policy rule to prevent weak,
vulnerable protocols and algorithms from allowing questionable traffic on your
network.

After defining the match criteria for the rule, select Options and configure the following
settings:
1. For Action, select Decrypt.
2. For Type, select SSH Proxy.
3. (Optional but a best practice) Configure or select an existing Decryption Profile to block
and control various aspects of the decrypted traffic (for example, you can use a profile to
terminate sessions with unsupported SSH versions and unsupported algorithms).
4. Click OK to save the rule.

STEP 3 | (Optional) Block all SSH tunnel traffic.

1. Configure a Security policy rule for the ssh-tunnel application with the Action set to
Deny.
2. Configure a Security policy rule that allows traffic from the ssh application.

STEP 4 | Commit your changes.

STEP 5 | (Optional) Create decryption exclusions to disable decryption for certain types of traffic.

Decryption Administration 93 ©2026 Palo Alto Networks, Inc.

Enable Decryption

Test Decryption
Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

After you configure a best practice decryption profile and apply it to traffic, you can check
both the Decryption logs and Traffic logs to verify if the Next-Generation Firewall (NGFW) is
decrypting the traffic that you intend to decrypt and that it is not decrypting the traffic that
you don’t want to decrypt. This topic shows you how to check decryption using Traffic logs. In
addition, follow post-deployment decryption best practices to maintain the deployment.
• Strata Cloud Manager
• PAN-OS & Panorama

Test Decryption (Strata Cloud Manager)

Filter the Traffic logs for decrypted traffic sessions.
• Select Log Viewer > Firewall/Traffic.
• In the search field, enter the following query: ( Is Proxy = true).
This filter displays only logs in which the SSL proxy flag is on, meaning only decrypted traffic—
every log entry has the value true in the Decrypted column.
You can filter the traffic more granularly by adding more terms to the query. For example, to
filter for decrypted traffic going only to the destination IP address [Link], add the
query Destination Address = '[Link]'.

Filter the Traffic logs for SSL traffic sessions that were not decrypted.
• Select Log Viewer > Firewall/Traffic.
• In the search field, enter one of the following queries:
• (Is Proxy != true) AND (Application = 'SSL')
• (Is Decrypted = False) AND (Application = 'SSL')
This filter displays only logs in which the SSL proxy flag is off (meaning only encrypted traffic)
and the traffic is SSL traffic; every log entry has the value false in the Decrypted column and
the value ssl in the Application column.
Similar to the example for viewing decrypted Traffic logs, you can add terms to filter the traffic
that you don’t decrypt in a more granular fashion.

Decryption Administration 94 ©2026 Palo Alto Networks, Inc.

Enable Decryption

Filter the Traffic logs for a particular session.

• Select Log Viewer > Firewall/Traffic.
• Filter on the Session ID using the query Session ID = Session ID value. For
example, to see the log for a session with the ID 137020, enter the query: Session ID
= 137020). You can find the ID number in the Session ID column in the log output, as
shown in the previous screens. If the Session ID column isn’t visible, add the column to the
output.

Filter the Traffic logs for all TLS and SSH traffic.
• Select Log Viewer > Firewall/Traffic.
• To view both decrypted and undecrypted TLS and SSH traffic, use the query: Is
Encrypted != 0.

Drill down into the log details.

To view more information about a particular log entry, click the log details icon ( ). For
example, for Session ID 137020 (shown in the previous bullet), the detailed log looks like this:
The box for the Decrypted flag provides a second way to verify if traffic was decrypted.
You can also take upstream and downstream packet captures of decrypted traffic to view
how the NGFW processes SSL traffic and takes actions on packets, or perform deep packet
inspection.

Test Decryption (PAN-OS)

Decryption Administration 95 ©2026 Palo Alto Networks, Inc.

Enable Decryption

View Decrypted Traffic Sessions—Filter the Traffic Logs (Monitor > Logs > Traffic) using the
filter ( flags has proxy ).
This filter displays only logs in which the SSL proxy flag is on, meaning only decrypted traffic—
every log entry has the value yes in the Decrypted column.

You can filter the traffic in a more granular fashion by adding more terms to the filter.
For example, you can filter for decrypted traffic going only to the destination IP address
[Link] by adding the filter ( [Link] in [Link] ):

Decryption Administration 96 ©2026 Palo Alto Networks, Inc.

Enable Decryption

View SSL Traffic Sessions That Are Not Decrypted—Filter the Traffic Logs (Monitor > Logs >
Traffic) using the filter ( not flags has proxy ) and ( app eq ssl ).
This filter displays only logs in which the SSL proxy flag is off (meaning only encrypted traffic)
and the traffic is SSL traffic; every log entry has the value no in the Decrypted column and the
value ssl in the Application column.

Similar to the example for viewing decrypted traffic logs, you can add terms to filter the traffic
that you don’t decrypt in a more granular fashion.

View The Log for a Particular Session—To view the Traffic log for a particular session, filter on
the Session ID.
For example, to see the log for a session with the ID 137020, filter using the term
( sessionid eq 137020). You can find the ID number in the Session ID column in the
log output, as shown in the previous screens. If the Session ID column isn’t displayed, add the
column to the output.

Decryption Administration 97 ©2026 Palo Alto Networks, Inc.

Enable Decryption

View All TLS and SSH Traffic—Filter the Traffic Logs (Monitor > Logs > Traffic) to view both
decrypted and undecrypted TLS and SSH traffic, use the filter ( s_encrypted neq 0 ):

Decryption Administration 98 ©2026 Palo Alto Networks, Inc.

Enable Decryption

Drill Down Into the Details—To view more information about a particular log entry, click the
magnifying glass to see a detailed log view. For example, for Session ID 137020 (shown in the
previous bullet), the detailed log looks like this:

The box for the Decrypted flag provides a second way to verify if traffic was decrypted.
You can also take upstream and downstream packet captures of decrypted traffic to view
how the NGFW processes SSL traffic and takes actions on packets, or perform deep packet
inspection.

Decryption Administration 99 ©2026 Palo Alto Networks, Inc.

Enable Decryption

Decryption Administration 100 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions
Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Not all traffic can or should be decrypted. For example, the QUIC (Quick UDP Internet
Connections) protocol uses a proprietary encryption over UDP, which cannot be decrypted.
However, you can block the protocol, forcing browsers to use the SSL/TLS protocol, which
enables the traffic to be inspected. Some traffic is automatically excluded from decryption for
not optimally working with decryption. These websites are added to the Local SSL Decryption
Exclusion Cache. Palo Alto Networks also maintains a predefined SSL decryption exclusion list
that excludes commonly used websites that break decryption. Sites on in the predefined exclusion
list and local cache remain encrypted; no policy rules are enforced on them.
You can also exclude traffic from decryption by adding a website to a custom SSL decryption
exclusion list or creating a decryption policy rule that excludes the website from decryption based
on URL categories, source, or other conditions. With a decryption exclusion, all traffic originating
from or destined to the targeted server remains encrypted. In general, two types of traffic can be
excluded from decryption:
• Traffic that breaks decryption for technical reasons, such as using a pinned certificate, an
incomplete certificate chain, unsupported ciphers, or mutual authentication (attempting to
decrypt the traffic results in blocking the traffic). There are two constructs for sites that break
decryption for technical reasons and therefore need to be excluded from decryption: the
predefined SSL decryption exclusion list and the Local SSL Decryption Exclusion Cache. If a
website whose applications and services break decryption technically are not in the predefined
SSL decryption exclusion list or the local SSL decryption cache, the NGFW blocks them unless
you add them to a custom SSL decryption exclusion list.
• The predefined SSL decryption exclusion list consists of the servers (with applications
and servers) that Palo Alto Networks has identified that break decryption technically and
permanent decryption exclusions that you manually add. If you encounter sites that break
decryption technically and are not on the predefined decryption exclusion list, add the
server hostname to the list. Content updates keep the list up to date.
• The Local SSL Decryption Exclusion Cache contains servers and websites that the NGFW
automatically excludes from decryption for 12 hours because they break decryption
for technical reasons, provided that the decryption profile applied to the traffic allows
unsupported modes. If unsupported modes are blocked, then the traffic is blocked instead
of added to the local cache.
• Traffic that you choose not to decrypt because of business, regulatory, personal, or other
reasons, such as financial-services, health-and-medicine, or government traffic. Create a policy-
based decryption exclusion to exclude this traffic based on source, destination, URL category,
or service.

101
Decryption Exclusions

To increase visibility into traffic and reduce the attack surface as much as possible, don’t
make decryption exceptions unless you must.

Whether adding an entry to a custom SSL decryption exclusion list, a custom URL category,
or external dynamic list, or other object to use in a policy-based exception, use asterisks (*) as
wildcards to create an entry that corresponds to multiple hostnames associated with a domain.
Asterisks behave the same way that carets (^) behave for URL category exceptions—each asterisk
controls one variable subdomain (label) in the hostname. This enables you to create both very
specific and very general exclusions.
Example Decryption Exclusion Entries:
• mail.*.com matches [Link] but does not match [Link]
• *.[Link] matches [Link] but does not match [Link]
• *.*.[Link] matches [Link] but does not match [Link]
• *.*.*.[Link] matches [Link] but does not match
[Link]
• [Link].* matches [Link] but does not match [Link]
• [Link].*.* matches [Link] but does not match [Link]
To exclude [Link] from decryption but not [Link], add
*.*.[Link] to the SSL decryption exclusion list.

Decryption Administration 102 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions

Local SSL Decryption Exclusion Cache

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

The Local SSL Decryption Exclusion Cache contains websites that the Next-Generation Firewall
(NGFW) automatically excludes from decryption because of technical circumstances that
break or prevent decryption, such as pinned certificates, client authentication, or unsupported
ciphers. The NGFW doesn’t decrypt, inspect, and enforce Security policy rules on traffic that
the cache allows because the traffic remains encrypted. However, traffic in the local cache is
excluded from decryption for 12 hours and then ages out. The NGFW populates the cache
based on the decryption profile associated with the decryption policy rule that controls the
traffic. Specifically, if the decryption profile allows unsupported modes—sessions with client
authentication, unsupported versions, or unsupported cipher suites—and the allowed traffic uses
an unsupported mode, then the device adds the server to the local exclusion cache. Ensure that
the sites you exclude from decryption (for example, by applying a decryption profile that allows
unsupported modes) are sites with applications or services you need for business.
If you allow unsupported mode checks in a decryption profile, the NGFW adds entries to the
cache when:
• The client or server advertises a specific cipher that the server or client doesn’t support.
• The client or server advertises a specific curve that the server or client doesn’t support.
• The client or server advertises a specific protocol version that the server or client doesn't
support.
• Examples: The client supports only TLSv1.2, but the server supports only TLSv1.3. In the
local cache, the Reason shown for this exclusion is SSL_UNSUPPORTED.
• The client supports TLSv1.3 and TLSv1.2, but the server supports only TLSv1.2. In this case,
the Reason shown is TLS13_UNSUPPORTED.

When the Reason for adding a server to the Local SSL Decryption Exclusion Cache is
TLS13_UNSUPPORTED, the NGFW downgrades the session protocol to TLSv1.2, so
it can decrypt and inspect the traffic.
If the decryption profile blocks unsupported modes, the server is not added to the local cache
and the NGFW blocks traffic to and from the server. Blocking unsupported modes blocks
communication with applications that use those modes to increase security. Client authentication
is a common reason for excluding applications from decryption, which is why best practice
is to block unsupported versions and unsupported ciphers and allow client authentication in
the decryption profile. If the decryption profile allows client authentication and a client starts
a session with a server that requires the client to authenticate, instead of blocking the traffic
because the NGFW can’t decrypt it, the application and server are added to the local exclusion
cache, which allows the traffic.

Decryption Administration 103 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions

If you allow traffic from sites that use client authentication and are not in the predefined
or custom SSL decryption exclusion list, create a decryption profile that allows sessions
with client authentication. Add the profile to a decryption policy rule that applies only to
the servers that host the application.
To increase security further, require multi-factor authentication to complete the user
login process. Alternatively, you can add the site to the SSL decryption exclusion list to
bypass decryption without using an explicit decryption policy rule.

The local cache contains a maximum of 1,024 entries. Each exclusion entry includes information
about the application, the server, the reason for inclusion in the cache, the decryption profile
applied to the traffic, its virtual system (vsys), and more. You can’t manually add local exclusions to
the cache, but you can add exclusions to the SSL decryption exclusion list .
To view the Local SSL Decryption Exclusion Cache, superuser or Certificate Management
administrative access is required.
• (PAN-OS and Panorama) Select Device > Certificate Management > SSL Decryption Exclusion,
and then click Show Local Exclusion Cache.

You can select and delete entries from the local cache manually. You can also delete
cached entries using the clear ssl-decrypt exclude-cache [server <value>]
[application <value>] CLI command.

Decryption Administration 104 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions

If anyone attempts to access the same server before the local cache entry ages out (12 hours),
the NGFW matches the session to the cache entry, bypasses decryption, and allows the traffic.
The NGFW flushes the local exclusion cache if you change the decryption policy rule or profile
because those changes might affect the classification of the session. If the cache becomes full, the
oldest entries are purged as new ones arrive.

Decryption Administration 105 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions

Palo Alto Networks Predefined Decryption Exclusions

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Palo Alto Networks provides a predefined list of commonly accessed sites that break decryption
or do not work optimally due to technical reasons, such as pinned certificates and mutual
authentication. Websites on the SSL decryption exclusion list are nondecryptable and excluded
from decryption by default. The Next-Generation Firewall (NGFW) evaluates traffic against
Security policy rules to determine if the encrypted traffic is allowed. It can't inspect or provide
further security enforcement of the traffic because the traffic remains encrypted. Palo Alto
Networks refreshes the predefined decryption exclusions list as part of its Applications and
Threats content updates (or the Applications content update, if you don’t have a Threat
Prevention license).
You can disable a predefined exclusion. For example, you may want to enforce a strict Security
policy rule that allows only applications and services that the NGFW can decrypt and on which it
can enforce Security policy rules. The NGFW blocks sites whose applications and services break
decryption technically if they are not enabled on a predefined or custom exclusion list. Add an
entry to the custom decryption exclusion list if it isn't on the predefined list.

The SSL decryption exclusion list is not for sites that you choose not to decrypt for legal,
regulatory, business, privacy, or other volitional reasons. For traffic, such as IP addresses,
users, URL categories, services, and even entire zones that you choose not to decrypt,
create a no-decryption policy rule.

To view and manage Palo Alto Networks predefined SSL decryption exclusions directly:
• (PAN-OS and Panorama) Select Device > Certificate Management > SSL Decryption
Exclusions.
• (Strata Cloud Manager) Select Manage > Configuration > NGFW and Prisma Access
> Security Services > Decryption. Then, under Global Decryption Exclusions, by Non-
Decryptable Sites (Predefined), click the range of predefined exclusions to open the list.

Decryption Administration 106 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions

The Hostname displays the name of the host that houses the application or service that breaks
decryption technically.
The Description (PAN-OS and Panorama) or Reason for Decryption Reason displays the reason
the site’s traffic is non-decryptable. For example, if pinned certificate is the reason, you'd see
pinned-cert on an NGFW or Panorama and Pinned Certificate on Strata Cloud Manager.
The NGFW, Panorama, or Strata Cloud Manager automatically removes enabled predefined
SSL decryption exclusions from the list when they become obsolete (the application becomes
supported with decryption). On an NGFW and Panorama, Show Obsoletes checks if any disabled

Decryption Administration 107 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions

predefined exclusions remain on the list and are no longer needed. The NGFW does not remove
disabled entries automatically, but you can select and Delete obsolete entries.
To disable predefined sites in the decryption exclusion list:
• (PAN-OS and Panorama)
1. Select Device > Certificate Management > SSL Decryption Exclusions.
2. Select the check box of the Hostname you want to remove, and then click Disable.
3. Commit the configuration.
• (Strata Cloud Manager)
1. Select Manage > Configuration > NGFW and Prisma Access > Security Services >
Decryption.
2. Under Global Decryption Exclusions, by Non-Decryptable Sites (Predefined), click the range
of predefined exclusions to open the list.
3. Select the check box of the Hostname you want to disable, and then click Disable.
4. Push Config

Decryption Administration 108 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions

Exclude a Server from Decryption for Technical Reasons

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Sometimes applications, websites, or services encounter technical issues when decryption is

attempted. Reasons that sites break decryption technically include pinned certificates, client
authentication, incomplete certificate chains, and unsupported ciphers. For HTTP public key
pinning (HPKP), most browsers that use HPKP permit Forward Proxy decryption as long as you
install the enterprise CA certificate (or the certificate chain) on the client. The most common sites
that break decryption or do not work optimally are included in Palo Alto Networks predefined
decryption exclusion list.
If decryption breaks an important application or service technically, you can add the hostname
of the site hosting the application or service to a custom SSL decryption exclusion list. The
Next-Generation Firewall (NGFW) doesn’t decrypt, inspect, or apply Security policy rules or
decryption policy rules to traffic on this list. For example, an internal custom application that
breaks decryption but is business-critical should be added to the list so the custom application
traffic is allowed. If a website whose applications and services break decryption technically is not
on either the predefined or custom decryption exclusion list, it is blocked. For security purposes,
be sure that only sites you need for business purposes are added to this list.

Before adding a custom exclusion, check the predefined exclusion list. If the hostname is
already listed, a custom entry is not required.

The SSL decryption exclusion list is not for sites you intentionally do not decrypt for legal,
regulatory, business, or privacy reasons. For traffic you choose not to decrypt, create a
policy-based decryption exclusion.

If the technical reason for excluding a site from decryption is an incomplete certificate
chain, the NGFW doesn’t automatically fix the chain as a browser would. If you need to
add a site to the SSL decryption exclusion list, review the site to ensure it’s a legitimate
business site, then download the missing sub-CA certificates and load and deploy them
onto the NGFW or an NGFW or Prisma Access management interfaces.

After a server is added to the SSL decryption exclusion list, the NGFW compares the server
hostname in the decryption exclusion entry against both the Server Name Indication (SNI) in the
client hello message and the Common Name (CN) in the server certificate. If either the SNI or CN
matches the entry, the NGFW does not decrypt the traffic.
• Strata Cloud Manager
• PAN-OS & Panorama

Decryption Administration 109 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions

Exclude a Server from Decryption for Technical Reasons (Strata

Cloud Manager)
STEP 1 | Log in to Strata Cloud Manager.

STEP 2 | Navigate to the Global Decryption Exclusions settings.

Select Configuration > NGFW and Prisma Access > Security Services > Decryption.

STEP 3 | Add an entry to the Custom Exclusions list.

1. Click the + (plus icon).
2. Enter the Hostname of the website or application you want to exclude from decryption.
The hostname is case-sensitive.

Make sure that the hostname is unique for each entry. If the hostname of a
predefined exclusion matches the hostname of a custom entry, the custom entry
takes precedence.
You can use wildcards to exclude multiple hostnames associated with a domain.
The NGFW does not decrypt the sessions if the server presents a Common
Name (CN) that matches the domain.
3. (Optional) Enter a Description.
4. Save your entry.

STEP 4 | Commit your changes.

Select Push Config > Push.

Exclude a Server from Decryption for Technical Reasons (PAN-OS)

STEP 1 | Log in to the web interface.

STEP 2 | Navigate to the SSL Decryption Exclusions list.

Select Device > Certificate Management > SSL Decryption Exclusions.

Decryption Administration 110 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions

STEP 3 | Add a new decryption exclusion, or select an existing custom entry to modify.
1. Enter the hostname of the website or application you want to exclude from decryption.
The hostname is case-sensitive.

Make sure that the hostname field is unique for each custom entry. If a
predefined exclusion matches a custom entry, the custom entry takes
precedence.
You can use wildcards to exclude multiple hostnames associated with a domain.
The NGFW does not decrypt the sessions if the server presents a Common
Name (CN) that matches the domain.
2. (Optional) To share the exclusion across all virtual systems in a multiple virtual system
NGFW, select Shared.
3. Exclude the application from decryption.
In contrast, you can deselect this option to begin decrypting an entry that was previously
excluded from decryption.
4. Click OK.

STEP 4 | Commit your changes.

Decryption Administration 111 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions

Exclude Traffic from Decryption for Business, Legal, or

Regulatory Reasons
Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Policy-based decryption exclusions are for excluding traffic that you choose not to decrypt. You
can create a policy-based decryption exclusion based on any combination of the traffic’s source,
destination, service, or URL category. Examples of traffic you may intentionally not decrypt, or
reasons not to decrypt this traffic:
• Traffic that contains personally identifiable information (PII) or other sensitive information,
such as traffic to the financial-services, health-and-medicine, and government URL categories.
• Traffic that originates or is destined for executives or other users whose traffic shouldn’t be
decrypted.
• Traffic to devices such as finance servers.
• Applications where privacy and the user experience are prioritized over security.
• Decryption of the traffic is prohibited by laws or local regulation. An example of not decrypting
traffic for regulatory and legal compliance is the European Union (EU) General Data Protection
Regulation (GDPR). The EU GDPR will require strong protection of all personal data for all
individuals. The GDPR affects all companies, including foreign companies, that collect or
process the personal data of EU residents.
Different regulations and compliance rules may mean that you treat the same data differently
in different countries or regions. Businesses usually can decrypt personal information in their
corporate data centers because the business owns the information. The best practice is to
decrypt as much traffic as possible so that you can see it and apply security protection to it.
You can specify websites to exclude from decryption using a predefined URL category, a custom
URL category (URL List type), or an external dynamic list, which define a dynamic, custom list
of URLs. Custom URL categories are ideal for static, infrequently changing lists of URLs. In
environments with dynamically changing IP addresses, such as Office 365, or where you make
frequent changes to the URL list, it’s often preferable to use an external dynamic list. Changes to
external dynamic lists are less disruptive because changes are applied dynamically; a configuration
commit is not necessary. In contrast, custom URL categories require a commit for any changes to
take effect.

Create an external dynamic list or a custom URL category that contains all the categories
you choose not to decrypt so that one decryption policy rule governs the encrypted
traffic you choose to allow. Apply a no-decryption profile to the rule. The ability to add
categories to an external dynamic list or a custom URL category makes it easy to exclude
traffic from decryption and helps keep the rulebase clean.

Decryption Administration 112 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions

The Next-Generation Firewall (NGFW) compares incoming traffic to decryption policy rules in the
order they are placed in the decryption rulebase. As such, best practice is to place the following
exclusion rules at the top of the decryption rulebase, in the following order:
1. IP address-based exceptions for sensitive destination servers.
2. Source-user based exceptions for executives and other users or groups.
3. Custom URL or external dynamic list-based exceptions for destination URLs.
4. Sensitive predefined URL category-based exceptions for destination URLs of entire categories
such as financial-services, health-and-medicine, and government.
Placing exclusions at the top of the rulebase prevents inadvertent decryption of sensitive traffic or
traffic that laws and regulations prohibit from decryption.
• Strata Cloud Manager
• PAN-OS & Panorama

Exclude Traffic from Decryption for Business, Legal, or Regulatory

Reasons (Strata Cloud Manager)
STEP 1 | Create a decryption policy rule or modify an existing rule.
Fill out basic information and all required fields under the Source, Destination, and Log
Settings sections. For source and destination Zones, select Any Zones, so that the no-decrypt
rule applies to all SSL traffic destined for an external server.

STEP 2 | Define match criteria for the traffic you want to exclude from decryption.
1. In the Services and URLs section, click Add URL Categories.
2. Select from predefined URL categories or Create New custom URL categories. The
NGFW excludes traffic to selected categories from decryption unless you create an
exception rule.
You can also Add External Dynamic Lists or Add SaaS Application Endpoints.

STEP 3 | Specify that you don't want to decrypt traffic matching the rule.
In the Action and Advanced Inspection section, for Action, select Do Not Decrypt.

STEP 4 | (Best Practice) Apply a decryption profile that blocks sessions with expired certificates and
untrusted issuers.
1. Configure or modify a no-decryption profile if you haven't already.
1. Select the No Decryption tab.
2. For Server Certificate Verification, select Block sessions with expired certificate and
Block sessions with untrusted issuer.
3. Save the profile.
2. In the Action and Advanced Inspection section, select the no-decrypt Decryption Profile.

STEP 5 | Save the rule.

Decryption Administration 113 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions

STEP 6 | Move (or drag and drop) the decryption exclusion rule to the top of the rulebase.
The NGFW enforces decryption rules against incoming traffic in the rulebase sequence and
enforces the first rule that matches the traffic.

STEP 7 | Save the configuration.

Select Push Config > Push.

Exclude Traffic from Decryption for Business, Legal, or Regulatory

Reasons (PAN-OS)
The following procedure shows how to exclude financial or health-related traffic from SSL
Forward Proxy decryption.

Decryption Administration 114 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions

STEP 1 | Exclude traffic from decryption based on match criteria.

1. Select Policies > Decryption and Add or modify a decryption policy rule.
2. Define the traffic that you want to exclude from decryption.
1. Enter a descriptive Name, such as No-Decrypt-Finance-Health.
2. For Source and Destination, select Any.
3. Select the Service/URL Category tab, and Add the financial-services and health-and-
medicine categories.

3. Select the Options tab, and for Action, select No Decrypt.

4. (Best Practice) For Decryption Profile, select a no-decryption profile that validates
certificates for sessions you don't want to decrypt.

Exception: Don’t attach a no-decryption profile to decryption policy rules for

TLSv1.3 traffic that you don’t decrypt because NGFWs can’t read the encrypted
certificate information so it can’t perform certificate checks. However, you
should still create a decryption policy rule for TLSv1.3 traffic that you don’t
decrypt because undecrypted traffic isn’t logged unless a decryption policy rule
controls that traffic.

If you haven't already, configure the decryption profile to Block sessions with expired
certificates and Block sessions with untrusted issuers.
5. Click OK.

STEP 2 | Place your decryption policy rule at the top of the decryption rulebase.
The NGFW enforces decryption rules against incoming traffic in the rulebase sequence and
enforces the first rule that the traffic matches.
Select the No-Decrypt-Finance-Health policy rule (Decryption > Policies), and click Move Up
until it appears at the top of the list, or drag and drop the rule.

Decryption Administration 115 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions

STEP 3 | Save the configuration.

Click Commit.

Decryption Administration 116 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions

Enable Users to Opt Out of SSL Decryption

Where Can I Use This? What Do I Need?

• No requirements.

You can alert end users who attempt to access HTTPS websites or applications that their traffic
will be decrypted and inspected for security purposes. The response page prompts them to either
continue to a website with the understanding that their traffic will be decrypted or opt out of the
decryption. Users can click Yes to continue to the site or click No to opt out of decryption and
terminate the session.
If they continue to the website, all HTTPS sites they access for the next 24 hours is subject
to decryption. After 24 hours, the response page appears again. Users who opt out of SSL
decryption can't access the requested webpage they initially tried to access or any other HTTPS
site, for the next minute. After the minute elapses, the response page appears the next time they
request an HTTPS website. (There is no option to go to the site and also bypass decryption.)
Before implementing the response page, educate end users about this intervention, what to
expect and when, and what their options are.

Browsers do not display response pages when SSL/TLS handshake inspections is

enabled.

You can activate the predefined SSL Decryption Opt-out Page or customize the page with your
own text or images. You can use the same response page objects documented for URL filtering.
However, best practice is to not provide end users with the option to bypass decryption.
To use the default page instead of an active custom page, delete the custom page from the
device and Commit your changes. This sets the predefined block page as the new, active page.
The Action column in the response page list shows if a response page is active–you'll see either
Predefined or Disabled.

Custom response pages larger than the maximum supported size are not decrypted or
displayed to users. The maximum size is 17,999 bytes.

STEP 1 | Activate the predefined SSL Decryption Opt-out Page.

1. Select Device > Response Pages,
2. In the Type column, select SSL Decryption Opt-out Page. If Location or Action shows
Disabled, then the page is inactive. The response page window appears.
3. Select Enable SSL Opt-out Page.
Alternatively, click Disabled in the row that corresponds to the SSL Decryption Opt-Out
page.
4. Click OK.
5. Commit the changes.

Decryption Administration 117 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions

STEP 2 | (Optional) Customize the SSL Decryption Opt-out Page.

1. Select Device > Response Pages.
2. Under Type, select SSL Decryption Opt-out Page. The predefined page displays under
the Location column.
3. Select the Predefined check box, and then click Export.
4. Using the HTML text editor of your choice, edit the page.
5. If you want to add an image, host the image on a web server that’s accessible from end-
user systems.
6. Add a line to the HTML to point to the image. For example:

<img src="[Link] [Link]?

1382722588"/>

7. Save the edited page with a new filename. Make sure that the page retains its UTF-8
encoding.
8. On the NGFW or Panorama, select Device > Response Pages.
9. Click SSL Decryption Opt-out Page.
10. Click Import and Browse to locate the file, or enter the path and filename in the Import
File field.
11. (Optional) Select the virtual system on which this login page will be used from the
Destination drop-down or select shared to make it available to all virtual systems.
12. Click OK to import the file.
13. Select the response page you imported, then Close the window.

STEP 3 | Verify that the response page displays when you attempt to browse to a site.
From a browser, go to an encrypted site that matches a decryption policy rule.

Decryption Administration 118 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions

Temporarily Disable TLS Decryption

Where Can I Use This? What Do I Need?

• Depending on the products you're using, you

need at least one of...
• For , an
For , no other requirements.

You can temporarily disable SSL/TLS decryption to troubleshoot or validate your decryption
deployment. For example, imagine a website does not display as expected and you suspect
decryption might be the cause. You can suspend SSL/TLS decryption until you confirm or rule
out decryption as the cause. Another scenario is a recent TLS decryption deployment that affects
specific applications and services but reviewing a vast decryption rulebase is impractical. In this
scenario, disabling decryption offers an efficient alternative to analyzing all decryption policy rules
and profiles.
You can use CLI commands to suspend SSL/TLS decryption and resume decryption when you're
ready. These operations don't require changes to decryption policy rules or a Commit of the
updated configuration, so you won't disrupt network traffic.

Disabling SSL decryption for any period of time impacts your security posture. Only
disable decryption for as long as necessary.

Disable SSL decryption.

The command to disable SSL decryption does not persist in the configuration after a
reboot. Decryption automatically resumes after a reboot, regardless of whether the
original issue has been fixed.

Use the set system setting ssl-decrypt skip-ssl-decrypt yes CLI command.

Re-enable SSL decryption.

Use the set system setting ssl-decrypt skip-ssl-decrypt no CLI command.

Decryption Administration 119 ©2026 Palo Alto Networks, Inc.

Decryption Exclusions

Decryption Administration 120 ©2026 Palo Alto Networks, Inc.

PQC and Decryption
Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Post-quantum cryptography (PQC), also known as quantum-resistant cryptography refers to a

cryptographic system designed to secure communications against the capabilities of quantum
and classical computers. As quantum computers advance, they will eventually be able to quickly
solve and break the public-key cryptographic systems widely trusted today. Quantum algorithms,
such as Shor's algorithm, have demonstrated the ability to efficiently factor large numbers, quickly
breaking classical cryptosystems. Another concern is Harvest Now, Decrypt Later attacks in which
bad actors collect and store encrypted data today with the intention of decrypting it later, when
the quantum computing tools needed to decrypt the data become available.
Post-quantum migration planning and preparation is critical given the current and evolving
quantum computing threat to security. NIST standardization, the deployment of post-quantum
algorithms and hybrid post-quantum algorithms by major enterprises and services, ongoing
discussions, and research add to the urgency of planning and transitioning to PQC.
Today, decryption provides visibility and insights that help you harden network security and
protect your organization from threats posed by early PQC use and advancements in post-
quantum computing. You can control and monitor the usage of PQC on your [Link] Palo
Alto Networks NGFW detects, blocks, and logs the use of PQC and hybrid PQC algorithms
in TLSv1.3 sessions. Decryption logs are an important tool for monitoring PQC activity on
your network. Logs offer visibility into potential security risks associated with current PQC
implementations and future quantum threats. Our decryption PQC enhancements aim to improve
visibility and facilitate informed decision-making that can protect your network infrastructure.
New support also prioritizes a smooth transition to PQC, maximum interoperability, and
adaptability to future advancements.
To prepare for the future, you can assess the vulnerabilities in your current infrastructure and
implement changes, such as blocking PQC use or deploying quantum-resistant VPNs.

The Quantum Security Administration guide provides additional context on post-

quantum cryptography, the quantum computing threat, preparing your organization for
quantum computing advancements, and features beyond decryption.

121
PQC and Decryption

Post-Quantum Cryptography Detection and Control

Where Can I Use This? What Do I Need?

• Depending on the products you're using, you

need at least one of...
• For , an
For , no other requirements.

Post-quantum cryptography (PQC) algorithms and hybrid PQC algorithms (classical and PQC
algorithms combined) are accessible through open-source libraries and integrated into web
browsers and other technologies. Traffic encrypted by PQC or hybrid PQC algorithms can't be
decrypted yet, making these algorithms vulnerable to misuse. However, you can prevent the
misuse of PQC and hybrid PQC algorithms and make informed decisions by monitoring PQC
activity on your network.
Using a Palo Alto Networks Next-Generation Firewall (NGFW), you can detect, block, and log
the use of PQC and hybrid PQC algorithms in TLSv1.3 sessions. This is done automatically based
on the settings in your decryption policy rules. Review your rules and update your decryption
configuration as needed to get the most visibility into PQC activity. These actions should be part
of your post-quantum migration planning and preparation strategy.
• How the NGFW Detects and Handles Post-Quantum Cryptography
• Post-Quantum Cryptography and Decryption Logs
• Decryption Configuration Recommendations

How the NGFW Detects and Handles Post-Quantum Cryptography

If SSL traffic matches an SSL Forward Proxy or SSL Inbound Inspection decryption policy rule,
the NGFW prevents negotiation with PQC, hybrid PQC, and other unsupported algorithms. The
following detection and blocking process enables the NGFW to continuously decrypt and identify
threats during a session:
1. ClientHello Inspection. The NGFW checks the ClientHello for the supported_groups TLS
extension. This extension specifies the groups that the client supports for key exchange.
2. Comparison of Values. The NGFW compares the hexadecimal value in the supported-groups
extension to a set of known values for PQC and hybrid PQC algorithms. This is how the NGFW
identifies the specific algorithms supported by the client.
3. Removal of Unsupported Algorithms. When SSL Forward Proxy and Inbound Inspection
decryption policy rules are applied, the NGFW removes PQC, hybrid PQC, and other
unsupported algorithms from the ClientHello. This forces the client to negotiate exclusively
with classical algorithms.
4. Session Restart and Negotiation with Classical Algorithms. The session restarts, and the client
and server negotiate with classical algorithms. (For a list of supported cipher suites, see PAN-
OS 11.1 Decryption Cipher Suites.)

Decryption Administration 122 ©2026 Palo Alto Networks, Inc.

PQC and Decryption

However, if the client strictly negotiates PQC, hybrid PQC, or other unsupported algorithms, the
NGFW drops the session.
If SSL traffic matches a “no-decrypt” decryption policy rule or doesn’t match any decryption policy
rules, the NGFW allows negotiation with PQC or hybrid PQC algorithms. However, details of
sessions that negotiate these algorithms are available in decryption logs only when session traffic
matches a “no-decrypt” decryption policy rule.

Post-Quantum Cryptography and Decryption Logs

Decryption logs provide visibility into post-quantum cryptography activity on your network for
sessions that negotiate PQC or hybrid PQC algorithms and match a “no decrypt” decryption
policy rule. The decryption logs for sessions matching this criteria include details such as the key
exchange (KE) and the negotiated EC curve.
In the case where SSL traffic matches an SSL Forward Proxy or SSL Inbound Inspection
decryption policy rule and the client only supports post-quantum algorithms, the session is
dropped. The error column in the corresponding decryption log states that the client only
supports post-quantum algorithms.

By default, the NGFW generates decryption logs for all unsuccessful TLS handshake traffic.
However, you can log both successful and unsuccessful TLS handshakes in the Log Settings of
decryption policy rules (Policies > Decryption > Options). Configure Decryption Logging shares
additional considerations.

Table 1: Summary of PQC Detection, Blocking, and Logging Behavior

The following table summarizes how the NGFW enforces and logs PQC activity.

If Decryption Policy Rule Triggered If Decryption If No Decryption

Policy Rule with Policy Rule Is
Client Supports Client Only
No-Decrypt Triggered
Classical Supports PQC
Action Triggered
Algorithms or Hybrid PQC
Algorithms

Session Status PQC and PQC algorithms Session Session

hybrid PQC are stripped successfully successfully
algorithms are from the negotiates with negotiates with
stripped from ClientHello, and a PQC or hybrid PQC or hybrid
the ClientHello, the session is PQC algorithm PQC algorithm
and the session dropped (no decryption) (no decryption)
restarts with
classical
algorithms

Decryption Log Decryption logs Log records The Negotiated No log

Behavior note negotiation the “Client EC Curve generated

Decryption Administration 123 ©2026 Palo Alto Networks, Inc.

PQC and Decryption

If Decryption Policy Rule Triggered If Decryption If No Decryption

Policy Rule with Policy Rule Is
Client Supports Client Only
No-Decrypt Triggered
Classical Supports PQC
Action Triggered
Algorithms or Hybrid PQC
Algorithms
of a classical only supports column records
algorithm (a Post-Quantum the name of the
PQC algorithm algorithms" error PQC or hybrid
isn’t noted message PQC algorithm
as it wasn’t negotiated
negotiated)

Decryption Configuration Recommendations

Review the logging settings in your decryption policy rules and use other tools for enhanced
visibility and control over PQC and hybrid PQC activity in your network. The following
recommendations assume a security-first approach to detection, enforcement, and logging:
• Log successful and unsuccessful handshakes in the Log Settings of decryption policy rules.
Select Policies > Decryption > Options, and then select Log Successful SSL Handshakes and
Log Unsuccessful SSL Handshakes.

Logging all TLS handshakes may increase the volume of logs on your system. The
default quota for decryption logs is one percent of your NGFW's log storage capacity.
To configure a larger log storage space quota for decryption logs, select Device >
Setup > Management > Logging and Reporting Settings > Log Storage. (Configure
Decryption Logging provides more details.)
• Create exclusions or separate rules for internal testing of PQC and hybrid PQC algorithms.
• To log traffic that you don’t decrypt, create a policy-based decryption exclusion or apply a “no
decrypt” decryption profile to the decryption policy rules that govern this traffic.
• Review the global counter for PQC and hybrid PQC algorithms. The counter increments
whenever a client attempts to negotiate with a PQC or hybrid PQC algorithm. Use the
following CLI command: show counter global name ssl_pqc_session_cnt.

Decryption Administration 124 ©2026 Palo Alto Networks, Inc.

Monitor Decryption
Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Decryption enhances visibility into your network and potential threats, serving as a monitoring
tool itself. Monitor decryption activity to understand what's happening on your network,
evaluate the effectiveness of your deployment against requirements and goals, and address
any weaknesses or issues. This practice is crucial during the proof-of-concept phase and should
continue as long as you decrypt. In fact, regular monitoring is a post-deployment SSL decryption
best practice. You can't see what you don't decrypt, but you also can't decrypt effectively without
evaluating efficacy.
Monitoring and troubleshooting go hand-in-hand. Various tools and features enable you to
monitor, analyze, and troubleshoot:

Not all monitoring tools are available on each management interface. For information,
refer to the Platform Support for Monitoring Tools table and the support tables in
Decryption Monitoring Tools.

• Decryption logs provide comprehensive information about individual sessions that match
decryption policy rules, including no-decrypt rules, and GlobalProtect sessions (if you enable
decryption logging in GlobalProtect Portal or GlobalProtect Gateways configuration). You
can log unsuccessful and successful TLS handshakes; unsuccessful handshakes are logged by
default.
• Application Command Center (ACC) SSL Activity widgets provide details about successful and
unsuccessful decryption activity in your network, including decryption failures, TLS versions,
key exchanges, and the amount and type of decrypted and undecrypted traffic.
• Custom decryption reports are based on decryption logs, predefined templates, and other
conditions that you can export to various formats.
• The Local SSL Decryption Exclusion Cache and Palo Alto Networks Predefined Decryption
Exclusions includes websites and servers that break decryption for technical reasons such as
certificate pinning. These websites and servers are automatically excluded from decryption.
Content updates keep the list up-to-date.
You can add servers to an SSL decryption exclusion list. However, you can't add websites to
the local cache as the NGFW automatically adds these servers provided that the decryption
profile applied to the traffic allows unsupported modes.
• Decryption mirroring creates a copy of decrypted traffic from an NGFW and sends it to a
traffic collection tool such as NetWitness or Solera, which can receive raw packet captures for
archiving and analysis.

125
Monitor Decryption

You can use these tools to identify specific metrics, data patterns, and anomalies. Decryption Logs
and Other Monitoring Tools describes these tools in more detail. For example, you can:
• Identify traffic causing decryption failures by Service Name Identification (SNI) and application
• Identify traffic using weak protocols and algorithms
• Monitor successful and unsuccessful decryption activity in your network
• Track the number of blocked sessions
• Identify potential weakness in your decryption policy rules and profiles
The Troubleshooting Decryption chapter provides examples and explanations of using these tools
to identify, investigate, and resolve issues with your decryption deployment. Focus is given to
commonly encountered issues. Understanding how and which tools to use for what issues help
you investigate and address a wide range of decryption issues.
The following table lists the monitoring tools available for the major management interfaces.

Table 2: Platform Support for Monitoring Tools

Platform Monitoring Tool

Next-Generation Firewall (PAN-OS & • Decryption logs

Panorama)
• ACC widgets
• Reports
• Local Decryption Exclusion Cache
• Predefined decryption exclusion list
• Decryption Port Mirroring

Prisma Access and NGFW (Strata Cloud • Reports

Manager)
• Local Decryption Exclusion Cache
• Predefined decryption exclusion list

Decryption Administration 126 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Decryption Logs and Other Monitoring Tools

You can use decryption logs and other tools to examine decrypted and undecrypted traffic on
your network and observe specific metrics, data, patterns, and anomalies, including:
• Traffic causing decryption failures by Service Name Identification (SNI) and application
• Traffic using weak protocols and algorithms
• Successful and unsuccessful decryption activity in your network
• Decryption statistics and information about adoption, failures, versions, algorithms, and more
• Number of blocked sessions
• Next-Generation Firewall (NGFW) performance, which helps you understand the impact of
decryption on throughput and verify if the NGFW is operating within acceptable norms. If you
want to decrypt more traffic than current resources support, scale up your NGFW deployment.
Additionally, these tools help you troubleshoot common decryption issues and improve your
decryption deployment and network security.

Decryption Logs
Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Decryption logs provide comprehensive information about individual sessions that match a
decryption policy rule. Details recorded in the logs include source and destination address,
TLS version, key exchange algorithm, encryption algorithm, authentication algorithm, and error
information. Beginning in PAN-OS 12.1.2, decryption logs differentiate between client-side and
server-side session attributes using "Client" and "Server" column headers. This distinction makes
it clear what is happening at each stage of the proxied connections. For example, the TLS version
negotiated between the client and the firewall appears under the "Client" header, while the TLS
version negotiated between the server and the firewall appears under the "Server" header. For a
complete list of fields, see Decryption Log Fields.
Monitor decryption logs to gain context about decrypted or undecrypted network traffic and
diagnose and resolve decryption issues. For example, if a session isn't decrypted as expected, you
can review the policy rule name and error message for the session to focus your investigation.
You can customize your log view by hiding or rearranging columns and filtering log entries by
specific characteristics.
By default, the NGFW logs all unsuccessful TLS handshake traffic. Consider logging successful
TLS handshakes for increased visibility, if you have sufficient log storage.

Decryption Administration 127 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Next-Generation Firewalls (NGFWs) don't generate decryption log entries for web traffic
blocked during SSL/TLS handshakes. These sessions don’t appear in decryption logs
because the NGFW prevents decryption when it resets the SSL/TLS connection. You can
view details of the blocked sessions in the URL filtering logs.
SSH Proxy traffic isn't captured in decryption logs. In addition, certificate information isn’t
available for session resumption logs.

Decryption Administration 128 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Decryption Administration 129 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

PAN-OS supports decryption logs for the following types of traffic:

Not all types of traffic support every parameter. Unsupported Parameters by Proxy
Type and TLS Version lists unsupported parameters for each proxy type.

• SSL Forward Proxy—Several fields only display information for Forward Proxy traffic, including
root CA (for trusted certificates only) and Server Name Identification (SNI)
The data for Forward Proxy traffic is based on whether the TLS handshake is successful or
unsuccessful. For unsuccessful TLS handshakes, the NGFW sends error data for the leg of the
transaction that caused the error, either client-to-NGFW or NGFW-to-server. For successful
TLS handshakes, the data is from the leg that successfully completes first, which is usually
client-to-NGFW.
• SSL Inbound Inspection
• No Decrypt (traffic excluded from decryption by decryption policy rules)

Because the session remains encrypted, the logs display less information. For
undecrypted TLSv1.3 traffic, there is no certificate information because TLSv1.3
encrypts certificate information.
• GlobalProtect™—Covers GlobalProtect gateway, GlobalProtect portal, and GlobalProtect
Clientless VPN (client-to-NGFW only)
• Decryption Mirror

The decryption log learns each session’s App-ID from Traffic logs. Enable Traffic logs
to see App-IDs in decryption logs. If Traffic logs are disabled, the App-ID shows as
incomplete. For example, GlobalProtect often generates intrazone traffic (Untrust zone to
Untrust zone), but the default intrazone policy doesn't enable Traffic logs. To see the App-
ID for GlobalProtect intrazone traffic, enable Traffic logs for intrazone traffic.
Another reason that an App-ID may display as incomplete is that for long sessions, the
NGFW may generate a decryption log before the Traffic log is complete (the Traffic
log usually generates at session end). In those cases, the App-ID is not available for the
decryption session. In addition, when the TLS handshake fails and generates an error
log, an App-ID is not available because the session terminates before the NGFW can
determine the App-ID. In these cases, the application may display as ssl or as incomplete.

When decryption logs are enabled, an NGFW sends HTTP/2 logs as Tunnel Inspection
logs (when decryption logs are disabled, HTTP/2 logs are sent as Traffic logs). Check the
Tunnel Inspection logs instead of the Traffic logs for HTTP/2 events.

Unsupported Parameters by Proxy Type and TLS Version

Decryption log fields display decryption session parameters for each decryption proxy type.
However, for reasons such as version support, encrypted portions of TLS handshakes, information
availability, some parameters are not available for every proxy type or TLS version. The following
table shows unsupported decryptions log parameters by proxy type and TLS version.

Decryption Administration 130 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Proxy Type Unsupported Parameter TLS Version

Forward Proxy Negotiated EC Curve TLSv1.3

Inbound Inspection Server Name Identification All

Root Common Name

Negotiated EC Curve TLSv1.3

No Decrypt (No Decrypt action in the Negotiated EC Curve TLSv1.2

decryption policy rule)
Server Name Identification

Negotiated EC Curve TLSv1.3

Server Name Identification
Certificate Information (all certificate
information fields, for example,
Certificate Start Date, Certificate End
Date, Certificate Key Type, etc.)

Network Packet Broker Negotiated EC Curve TLSv1.3

GlobalProtect Portal Server Name Identification All

Root Common Name
Decryption Policy Name
App-ID

GlobalProtect Gateway Server Name Identification All

Decryption Policy Name
App-ID

Clientless SSLVPN Server Name Identification All

SSH Decryption Log Not Supported

Cleartext Decryption Log Not Supported

Decryption Reports
Where Can I Use This? What Do I Need?

• Depending on the products you're using, you

• need at least one of...

Decryption Administration 131 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Where Can I Use This? What Do I Need?

• For :
A Prisma Access license and Cloud
Services plugin for
If you're using a , no other requirements.

Create custom reports for decryption events based on decryption log fields and predefined
templates that summarize decryption activity. Pinpoint the exact information you want to analyze
and then filter by conditions and log filters. You can also include Query Builders to dig deeper into
data in reports. Reports generate every night or at the scheduled time. You can export these into
PDF, CSV, and XML formats.

Local Decryption Exclusion Cache

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

The Local Decryption Exclusion Cache automatically adds servers that local users encounter that
break decryption for technical reasons and excludes them from decryption, provided that the
decryption profile applied to the traffic allows unsupported modes (if unsupported modes are
blocked, then the traffic is blocked instead of added to the cache). You can view this to see which
servers have automatically been excluded from decryption. This may explain certain behavior you
witness.

Decryption Application Command Center (ACC) Widgets

Where Can I Use This? What Do I Need?

• Depending on the products you're using, you

• need at least one of...
• For :
A Prisma Access license and Cloud
Services plugin for
If you're using a , no other requirements.

Decryption logs and the SSL Activity Widgets in the Application Command Center (ACC) provide
powerful decryption troubleshooting tools that work both independently and together. When you
gain an understanding of how to use these tools, you can investigate and address a wide range
of decryption issues. The following examples show you how to use the troubleshooting tools to

Decryption Administration 132 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

identify, investigate, and address decryption issues. Apply these methods to troubleshoot any
issues you encounter in your decryption deployment.
The Application Command Center (ACC) widgets for decryption (ACC > SSL Activity) introduced
in PAN-OS 11.1 work with decryption logs to help you diagnose and resolve decryption issues
quickly and easily. Use the SSL Activity widget to view and analyze network decryption activity
such as the number of decrypted and undecrypted sessions, how much traffic uses different
TLS protocol versions, the most common decryption failure reasons, and which applications and
Server Name Identifications (SNIs) use weak ciphers and algorithms. Next, use the decryption logs
to drill down into sessions and diagnose the exact issue so you can take appropriate action.
PAN-OS 11.1 introduced five new decryption widgets. Use the information the widgets provide
to identify misconfigured decryption policy rules and profiles and make informed decisions about
what traffic to allow and block:
• Traffic Activity—Shows SSL/TLS activity compared to non-SSL/TLS activity by total number of
sessions or amount of traffic in bytes.
• SSL/TLS Traffic—Shows the amount of decrypted and undecrypted traffic by number of
sessions or amount of traffic in bytes. Reasons for traffic not being decrypted include:
• No decryption policy rule is applied to the traffic.
• The decryption policy rule intentionally exempted the traffic from decryption (for example, a
no-decryption policy rule).
• The decryption policy rule was misconfigured and the traffic was intended to be decrypted
but is not.
• The site is in the SSL decryption exclusion list (Device > Certificate Management > SSL
Decryption Exclusion), which contains sites Palo Alto Networks has identified that break
decryption for technical reasons such as pinned certificates or client authentication. For
these sites, the NGFW bypasses decryption.
• The site is in the Local SSL Decryption Exclusion Cache, which contains sites that prevent
decryption for technical reasons.
The ACC only populates the next three widgets with data from traffic that a decryption policy rule
controls. If you don’t apply a decryption policy rule to traffic, that traffic does not populate these
widgets.
• Decryption Failure Reasons—Shows the reasons for decryption failures: protocol, certificate,
version, cipher, HSM, resource, resume, or feature issues, by SNI. Use this information to
detect problems caused by decryption policy rule or profile misconfigurations or by traffic that
uses unsupported weak protocols or algorithms. Click a failure reason to drill down and isolate
the number of sessions per SNI that experienced the failure or click an SNI to see all of the
decryption failures for that SNI.
• Successful TLS Version Activity—Shows successful TLS connections by TLS version for
applications or SNIs (SNIs are available for Forward Proxy only) so you can evaluate how
much risk you are taking on by allowing weaker TLS protocol versions. Identifying applications
and SNIs that use weak protocols enables you to evaluate each one and decide whether you
need to allow access to it for business reasons. If you don’t need the application for business
purposes, you may want to block the traffic instead of allowing it to reduce risk. Click a TLS
version to drill down and view the SNIs or applications that used that TLS version. Click an
application or an SNI to drill down and see how many of those application or SNI sessions used
each TLS version.

Decryption Administration 133 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

• Successful Key Exchange Activity—Shows successful key exchange activity per algorithm
for applications or SNIs (SNIs are available for Forward Proxy only). Click a key exchange
algorithm to see the activity for just that algorithm or click an application or SNI to view the
key exchange algorithm activity for that application or SNI.
The following example of drilling down into ACC data shows you how to examine successful TLS
version activity:
1. The Successful TLS Version Activity widget shows that 17 sessions used TLSv1.3 and seven
sessions used TLSv1.2. The SNI list shows the destination SNIs and the number of sessions per
SNI.

Decryption Administration 134 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

2. To see which SNIs used TLSv1.2, click the green bar labeled TLSv1.2.

3. Now, you can see the seven TLSv1.2 sessions were spread among four servers.

Decryption Administration 135 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

4. Clicking Home returns to the home screen. Now, clicking the [Link] SNI shows us
which TLS versions it used. We can see that two of the four sessions used TLSv1.3 and two
used TLSv1.2.

For any decryption widget, click the Jump to Logs icon to jump directly to the decryption logs that
correspond to the data in the ACC:

In the preceding example, at any point in the investigation you could jump to the decryption
logs for the data to drill down more. For example, you could examine the logs for the individual
sessions that used TLSv1.2 to find out why they didn’t use TLSv1.3.
Decryption ACC widgets show the name of the decrypted application based on the Palo Alto
Networks App-ID. For populating the ACC, the NGFW can only identify applications that have
a Palo Alto Networks App-ID; the NGFW can’t populate the ACC with custom applications or
applications that do not have an App-ID. Content updates update App-IDs regularly. Other
reasons that the application may be shown as incomplete or unknown are:
• The NGFW dropped the session before it could identify the application.
• Decryption logs depend on Traffic logs to populate the decryption log application field.
However, if the Traffic log isn’t completed in 60 seconds or less, the Traffic log does not
populate the application in the decryption log and the application displays as incomplete or
unknown.

Decryption Port Mirroring

Where Can I Use This? What Do I Need?

• All deployments, including those funded Decryption Port Mirroring license

by software NGFW credits

Decryption Administration 136 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Decryption mirroring creates a copy of decrypted traffic from an NGFW and sends it to a traffic
collection tool such as NetWitness or Solera, which can receive raw packet captures for archiving
and analysis. Organizations that require comprehensive data capture for forensic and historical
purposes or for data leak prevention can install a free license to enable the feature.
After you install the license, connect the traffic collection tool directly to an Ethernet interface on
the NGFW and set the Interface Type to Decrypt Mirror. The NGFW simulates a TCP handshake
with the collection tool and then sends every data packet through that interface, decrypted (as
cleartext).

VM-Series firewalls support decryption port mirroring in ESXi and Azure cloud
environments. To enable this feature on Azure, you must configure an Azure tap interface.

Decryption port mirroring is not available on the VM-Series for Google Cloud Platform and
VMware NSX.

Keep in mind that certain countries regulate the decryption, storage, inspection, or use of SSL
traffic, and user consent may be required to mirror traffic. Additionally, malicious users with
administrative access to the NGFW could potentially harvest usernames, passwords, social
security numbers, credit card numbers, or other sensitive information submitted through
encrypted channels. Palo Alto Networks recommends that you consult with corporate counsel
before activating and using this feature in a production environment.
The following graphic shows the process for mirroring decrypted traffic. Configure Decryption
Port Mirroring describes how to license and enable this feature.

Decryption Administration 137 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Configure Decryption Logging

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Decryption logs are generated for sessions governed by a decryption policy rule, including
sessions with a no-decrypt policy rule. Details such as the decryption policy rule that controls
the traffic, the cipher suite used, and other TLS handshake information help with monitoring
decryption activity and troubleshooting any issues. For example, you can filter decryption logs
by a specific decryption log error or error index to pinpoint and address specific issues such as
expired certificates.
By default, decryption logs record details of unsuccessful TLS handshakes. You can log successful
TLS handshakes in decryption policy rules.

If you log successful TLS handshakes, ensure that you have sufficient system resources (log
space).

Configure decryption logging in the decryption policy rules that control the traffic you want to
log. To log traffic that you don’t decrypt, create a policy-based decryption exclusion and, for rules
that govern TLSv1.2 and earlier traffic, apply a No-decryption profile to the decryption policy rule.
If you forward decryption logs for storage, ensure that you properly secure log transport and
storage because these logs contain sensitive information.

For reasons such as version support, encrypted portions of TLS handshakes, or information
availability, some parameters are not available for every proxy type or TLS version.
Unsupported Parameters by Proxy Type and TLS Version lists these parameters.

Next-Generation Firewalls (NGFWs) don't generate decryption log entries for web traffic
blocked during SSL/TLS handshakes. These sessions don’t appear in decryption logs
because the NGFW prevents decryption when it resets the SSL/TLS connection, ending
the handshake. You can view details of the blocked sessions in the URL filtering logs.
SSH Proxy traffic isn't captured in decryption logs. In addition, certificate information isn’t
available for session resumption logs.

• Strata Cloud Manager

• PAN-OS & Panorama

Configure Decryption Logging (Strata Cloud Manager)

The Log Viewer enables you to view and interact with decryption logs and other log types for
NGFW and Prisma Access deployments managed by Strata Cloud Manager.

Decryption Administration 138 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Logs are forwarded to the Strata Logging Service only with a valid license; otherwise, logs
are saved locally.

STEP 1 | Log in to Strata Cloud Manager.

STEP 2 | Create or modify a decryption policy rule to specify which traffic to log.

STEP 3 | Configure Log Settings in the decryption policy rule.

1. For Logging, select Log Successful TLS handshakes.
By default, Strata Cloud Manager logs unsuccessful handshakes.

Log successful handshakes as well as unsuccessful handshakes to gain visibility

into as much decrypted traffic as your device’s available resources permit
(don’t decrypt private or sensitive traffic; follow decryption best practices and
decrypt as much traffic as you can).
2. (Optional) Forward decryption logs to Dedicated Log Collectors, other storage devices,
or specific administrators.
If you forward decryption logs, be sure that the logs are stored securely as they contain
sensitive information.
1. Create a Log Forwarding profile to specify the decryption Log Type and the method
of forwarding the logs.
2. For External Log Forwarding, select the profile you created.

STEP 4 | Save your rule.

STEP 5 | Commit your changes.

Select Push Config > Push.

Configure Decryption Logging (PAN-OS)

Decryption Administration 139 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

STEP 1 | Configure the decryption traffic you want to log in a decryption policy rule (Policies >
Decryption).
By default, the NGFW logs only unsuccessful TLS handshakes:

Log successful handshakes as well as unsuccessful handshakes to gain visibility into

as much decrypted traffic as your device’s available resources permit (don’t decrypt
private or sensitive traffic; follow decryption best practices and decrypt as much
traffic as you can).

STEP 2 | Create a Log Forwarding profile to forward decryption logs to log collectors, other storage
devices, or specific administrators, and then specify the profile in the Log Forwarding field of
the decryption policy rule Options tab.
To forward decryption logs, you must configure a Log Forwarding profile (Objects > Log
Forwarding) to specify the decryption Log Type and method of forwarding the logs.

Store forwarded decryption logs securely because they contain sensitive information.

Decryption Administration 140 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

STEP 3 | If you log successful TLS handshakes in addition to unsuccessful TLS handshakes, configure
a larger log storage space quota (Device > Setup > Management > Logging and Reporting
Settings > Log Storage) for decryption logs.
The default quota (allocation) is one percent of the device’s log storage capacity for decryption
logs and one percent for the general decryption summary. There is no default allocation for
hourly, daily, or weekly decryption summaries.

Many factors determine the amount of storage you might need for decryption logs and they
depend on your deployment. For example, take these factors into account:
• The amount of TLS traffic that passes through the NGFW.
• The amount of TLS traffic that you decrypt.
• Your usage of other logs (evaluate from which logs you should take capacity to allocate to
decryption logs).
• If you log both successful and unsuccessful TLS handshakes, you probably need more
capacity than you need to only log unsuccessful TLS handshakes. Depending on the amount
of traffic you decrypt, decryption logs could consume as much capacity as Traffic logs

Decryption Administration 141 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

or Threat logs and may require a tradeoff among them if the device’s capacity is fully
subscribed.

The total combined allocation of log quotas cannot exceed 100% of the available
NGFW log resources.

You may need to experiment to find the right quota for each log category in your particular
deployment. If you only log unsuccessful handshakes, you could start with the default or
increase the allocation to two or three percent. If you log both successful and unsuccessful
handshakes, you could start by allocating about half of the space to decryption logs that you
allocate to Traffic logs. The logs from which you take the space to allocate to decryption logs
depends on your traffic, your business, and your monitoring requirements.

Decryption Administration 142 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Decryption Log Errors and Error Indexes

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

The Error Index and Error columns in decryption logs list error categories and details. You can also
see error and error index information in the Handshake Details section of the Detailed Log View
(click for any log entry). The Error Index column displays one of eight types of errors:

If no suitable error category exists for an error, the default message is General TLS
protocol error.

• Certificate—Errors such as invalid certificates, expired certificates, unsupported client

certificates, certificate revocation status check failures, and untrusted issuer CAs (sessions
signed by an untrusted root, which includes incomplete certificate chains).
• Cipher—Unsupported cipher errors where:
• The client tries to negotiate a cipher that the NGFW supports but the decryption profile
applied to the traffic doesn’t support.
• The client tries to negotiate a cipher that the NGFW doesn’t support.
• (Rare) Inbound Inspection is enabled and the server’s capabilities don’t match the decryption
profile settings.
• The error message includes the supported client cipher bitmask value and the supported
decryption profile cipher bitmask value. You can use these values to identify the cipher the
client tried to use and the ciphers that the decryption profile supports.
• Feature—Errors such as oversized TLS handshakes or unknown handshakes, oversized
certificate chains (more than five certificates), and other unsupported features.
• HSM—Hardware storage module (HSM) errors such as unknown requests, items not found in
the configuration, request timeouts, and other HSM errors and failures.
• Protocol—Errors such as TLS handshake failures, private and public key mismatches,
Heartbleed errors, TLS key exchange failures, and other TLS protocol errors. Protocol errors
show when the server doesn’t support the protocols that the client supports, the server uses
certificate types that the NGFW doesn’t support, and general TLS protocol errors.
• Resource—Errors such as lack of sufficient memory.
• Resume—Session resumption errors concerning resume session IDs and tickets, resume session
entries in the NGFW cache, and other session resumption errors.
• Version—Errors regarding client and decryption profile version mismatches and client and
server version mismatches. The error messages include bitmask values that identify the

Decryption Administration 143 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

supported client and decryption profile versions. You can use these values to identify the
protocol version the client tried to use and the versions that the decryption profile supports.
The following sections include a table that lists the specific errors for each error category along
with additional information and resources. For some errors, possible remediation steps are
shared. Finally, the Root Status “Uninspected” section describes why the Root Status column in a
decryption log may display "uninspected."

Certificate Errors
Certificate errors are raised for reasons including invalid certificates, expired certificates,
unsupported client certificates, Online Certificate Status Protocol (OCSP) or certificate revocation
list (CRL) check failures, and untrusted issuer CAs (sessions signed by an untrusted root, which
includes incomplete certificate chains).

When the NGFW doesn’t have an intermediate certificate because the site didn't send
the full certificate chain, you can find and install the missing certificate to repair an
incomplete certificate chain.

Decryption Error Message Additional Information and Resources

Invalid (client or server) certificate Description: The certificate presented by

either a client or server is invalid or cannot be
verified.
Related Documentation:
• Certificate Management
• Certificate Revocation
Remediation:
• Use a certificate from a trusted external
CA (rather than an untrusted or self-signed
CA). See Obtain a certificate from an
External CA.
• Repair an incomplete certificate chain.
• Check if the other certificate errors are
applicable.

Expired (client or server) certificate Description: A certificate has expired or is

not currently valid.
RFC Information: This alert falls under the
certificate_expired error defined in RFC 5246,
which is applicable to TLSv1.1-TLSv1.3.
Related Documentation:Troubleshoot
Expired Certificates
Remediation:
• Renew the certificate.

Decryption Administration 144 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Decryption Error Message Additional Information and Resources

• Configure multiple certificates to use for
SSL Inbound Inspection, so you can ensure
a valid certificate is always available.

Unsupported client certificate Description: The client certificate was of an

unsupported type.
RFC Information: This alert falls under the
unsupported_certificate error defined in RFC
5246, which is applicable to TLSv1.1-TLSv1.3.

OCSP / CRL check: certificate revoked Description: A certificate was revoked by its
signer.
RFC Information: This alert falls under the
certificate_revoked error defined in RFC 5246,
which is applicable to TLSv1.1-TLSv1.3.
Related Documentation:
• Certificate Revocation
• Troubleshoot Revoked Certificates
Remediation:
• Replace (generate a new certificate) or
renew the certificate.
• Import a certificate and private key.

OCSP / CRL check failure Description: Sent by clients when an invalid

or unacceptable OCSP response is provided
by the server through the "status_request"
extension.
RFC Information: This alert falls under the
bad_certificate_status_response error defined
in RFC 8446, which is applicable to TLSv1.3.

Untrusted issuer CA Description: A valid certificate chain was

received, but the certificate authority (CA)
certificate could not be matched with a
known trust anchor.
RFC Information: This alert falls under the
unknown_ca error defined in RFC 5246, which
is applicable to TLSv1.1-TLSv1.3.
Related Documentation: Identify Untrusted
CA Certificates
Remediation: This error may be due to a
configuration issue. Use a certificate from a

Decryption Administration 145 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Decryption Error Message Additional Information and Resources

trusted external CA (rather than an untrusted
or self-signed CA). See Obtain a Certificate
from an External CA.

Received fatal alert <error name> from (client Description: The variable error has caused
or server) the connection to fail.

Server and firewall's certificate mismatch Description: The sender was unable to
negotiate an acceptable set of security
parameters with the receiver. A few possible
causes are: incorrect certificates, a missing
client certificate, an untrusted server
certificate, or a missing server certificate.
RFC Information: This alert falls under the
handshake_failure error defined in RFC 5246,
which is applicable to TLSv1.1-TLSv1.3.
Remediation:
• Verify that the server certificate has not
expired, and renew the certificate, if
necessary.
• Verify that the correct SSL certificate is
installed on the server.
• Reimport the server certificate onto the
NGFW. See Import a Certificate and
Private Key.

SNI didn't match with subject name or SAN Related Documentation: SSL Decryption and
Subject Alternative Names (SAN)

General (client or server) certificate error This message indicates that an error
doesn't meet the criteria for any of the
aforementioned certificate errors.

Cipher Errors
Cipher errors are unsupported cipher errors where at least one of the following is true:
• The client tries to negotiate a cipher that the NGFW supports but that the decryption profile
applied to the traffic doesn’t support.
• The client tries to negotiate a cipher that the NGFW doesn’t support.
• (Rare) Inbound Inspection is enabled and the server’s capabilities don’t match the decryption
profile settings.
• The error message includes the supported client cipher bitmask value and the supported
decryption profile cipher bitmask value. You can convert these values to actual values using

Decryption Administration 146 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

operational CLI commands to identify the cipher the client tried to use and to list the cipher
values that the decryption profile supports.

Decryption Error Message Additional Information and Resources

Unsupported cipher Description: The sender was unable to

negotiate an acceptable set of security
parameters with the receiver, likely due to
incompatible cipher suites.
RFC Information: This alert falls under the
handshake_failure error defined in RFC 5246,
which is applicable to TLSv1.1-TLSv1.3.
Remediation:
• Follow the steps to fix cipher errors.
• Configure your decryption profiles
such that the cipher suites selected are
compatible with your sender and receiver's
supported cipher suites. If needed, create a
new decryption policy rule for the specific
use case of your NGFW causing this issue.

Feature Errors
Feature errors include oversized TLS handshakes or unknown handshakes, oversized certificate
chains (more than five certificates), and other unsupported features.

Decryption Error Message Additional Information and Resources

Client certificate received Related Documentation:

• Keys and Certificates for Decryption
Policies
• Decryption Best Practices

Oversized chain (>5 certificates) received Description: The certificate chain contains
more than five certificates.
Remediation:
• Try replacing your certificate (or its
external CA) with one that requires
a smaller certificate chain (fewer
intermediate certificates). See Obtain a
Certificate from an External CA.

Oversized handshake received N/A

Decryption Administration 147 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Decryption Error Message Additional Information and Resources

Unknown handshake message received Description: A field in the handshake was

incorrect or inconsistent with other fields
(albeit conforms to the formal protocol
syntax), likely causing an unrecognizable
handshake message.
RFC Information: This alert falls under the
illegal_parameter error defined in RFC 5246,
which is applicable to TLSv1.1-TLSv1.3.

Unsupported feature This message indicates that an error

doesn't meet the criteria for any of the
aforementioned feature errors.

HSM Errors
Hardware storage module (HSM) errors include unknown requests, items not found in the
configuration, request timeouts, and other HSM errors and failures.

Decryption Error Message Additional Information and Resources

Unknown request N/A

Certificate not found in configuration Remediation:

• Generate or import a certificate using your
HSM.
• Generate a Certificate, and then import
this certificate onto your HSM.
• Store Private Keys on an HSM.

Private key not found on HSM Remediation:

• Store Private Keys on an HSM.
• Verify that you successfully imported
the certificate and private key used in
your decryption deployment. Check
the Key column for either a lock or
error icon. The error icon indicates the
private key is not on the HSM or the
HSM is not properly authenticated or
connected.
• Restart the HSM.
• Reset the HSM configuration. Select
Device > Setup > HSM, and then Reset

Decryption Administration 148 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Decryption Error Message Additional Information and Resources

HSM Configuration from the Hardware
Security Operations section.

Request to HSM timed out Troubleshooting:

• Verify NGFW connectivity and
authentication with the HSM.
• Select Device > Setup > HSM and look
for a green dot next to Status. This
indicates that the NGFW is successfully
connected and authenticated to the
HSM.
Remediation:
• Restart the HSM.
• Reset the HSM configuration. Select
Device > Setup > HSM, and then Reset
HSM Configuration from the Hardware
Security Operations section.

HSM is down Related Documentation:

• Set Up Connectivity with an HSM.
• Manage the HSM Deployment, which
includes tasks like viewing HSM
configuration settings, detailed HSM
information (for example, HSM status), and
resetting your HSM configuration.

Could not send request to HSM Related Documentation:

• Set Up Connectivity with an HSM.
• Manage the HSM Deployment includes
tasks like viewing HSM configuration
settings, detailed HSM information (for
example, HSM status), and resetting your
HSM configuration.
Remediation: Restart the HSM.

HSM server not found in configuration Related Documentation:

• Secure Keys with an HSM (general
information).
• Set Up Connectivity with an HSM.
• Managing an HSM Deployment includes
tasks like viewing HSM configuration
settings and detailed HSM information (for

Decryption Administration 149 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Decryption Error Message Additional Information and Resources

example, HSM status) and resetting your
HSM configuration.

General HSM failure This message indicates that an error

doesn't meet the criteria for any of the
aforementioned HSM errors.

Protocol Errors
Protocol errors include TLS handshake failures, private and public key mismatches, Heartbleed
errors, TLS key exchange failures, and other TLS protocol errors. Protocol errors show when the
server doesn’t support the protocols that the client supports, the server uses certificate types that
the NGFW doesn’t support, and general TLS protocol errors.

Decryption Error Message Additional Information and Resources

TLS Handshake Failure Description: The sender was unable to

negotiate an acceptable set of security
parameters with the receiver. A few possible
causes are: incompatible cipher suites,
incompatible SSL/TLS versions, incorrect
certificates, missing client certificate,
untrusted server certificate, or a missing
server certificate.
RFC Information: This alert falls under the
handshake_failure error defined in RFC 5246,
which is applicable to TLSv1.1-TLSv1.3.
Remediation:
• Fix cipher errors.
• Configure your decryption profiles
such that the cipher suites selected are
compatible with your sender and receiver's
supported cipher suites. If needed, create
a new decryption policy rule for a specific
use case of your NGFW causing this issue.
• Verify that the server certificate has not
expired.
• Make sure the certificate uses a trusted
external CA (rather than an untrusted or
self-signed CA). See Obtain a Certificate
from an External CA.
• Renew your certificate.
• Repair an incomplete certificate chain.

Decryption Administration 150 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Decryption Error Message Additional Information and Resources

Private key does not match public key Related Documentation:

• Deploy SSL Decryption Using Best
Practices
• Keys and Certificates for Decryption
Policies

TLS Key Exchange Failure Description: The client and server are unable
to exchange the keys needed to secure
communication. A few possible causes are:
incompatible cipher suites, incompatible SSL/
TLS versions, or an incomplete certificate
chain.
Remediation:
• Fix cipher errors.
• Configure your decryption profiles
such that the cipher suites selected are
compatible with your sender and receiver's
supported cipher suites. If needed, create
a new decryption policy rule for a specific
use case of your NGFW causing this issue.
• Repair an incomplete certificate chain.

OpenSSL Error Description: An OpenSSL error was detected.

Client only supports Post Quantum Description: The TLS handshake failed
Algorithms because the client does not support classical
algorithms.
Related Documentation:
• Quantum Security Concepts

General TLS Protocol Error This message indicates that an error

doesn't meet the criteria for any of the
aforementioned protocol errors.

If no suitable error category exists

for any error, this is the default
error message.

Resource Errors
Resource errors point to a lack of sufficient memory.

Decryption Administration 151 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Decryption Error Message Additional Information and Resources

Out of the firewall resources: memory Description: An internal error unrelated to the
peer or SSL/TLS protocol correctness (such as
a memory allocation error) makes it impossible
to continue.
RFC Information: This alert falls under the
internal_errors error defined in RFC 5246,
which is applicable to TLSv1.1-TLSv1.3.

Out of the firewall resources (general) This message indicates that an error
doesn't meet the criteria for any of the
aforementioned resource errors.

Resume Errors
Resume errors include session resumption errors concerning resume session IDs and tickets,
resumed session entries in the NGFW cache, and other session resumption errors.

Decryption Error Message Additional Information and Resources

No resume entry in firewall cache Description: The NGFW tried to resume a

session for which a cache entry doesn't exist.

General sessions resumption error This message indicates that an error

doesn't meet the criteria for any of the
aforementioned resume errors.

Version Errors
Version errors regard client and decryption profile version mismatches and client and server
version mismatches. The error messages include bitmask values that identify the supported client
and decryption profile versions. You can convert these values to actual values using operational
CLI commands to identify the cipher the client tried to use and to list the cipher values that the
decryption profile supports.

Decryption Error Message Additional Information and Resources

Client and decrypt profile version mismatch Description: The sender was unable to
negotiate an acceptable set of security
parameters with the receiver given the
available options. This is likely due to
incompatibility between the SSL/TLS versions
supported by the client and in the decryption
profile.

Decryption Administration 152 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Decryption Error Message Additional Information and Resources

RFC Information: This alert falls under the
handshake_failure error defined in RFC 5246,
which is applicable to TLSv1.1-TLSv1.3.
Related Documentation: Troubleshoot
Unsupported Cipher Suites
Remediation:
• Fix version errors.
• Configure decryption profiles that are
compatible with your sender and receiver's
SSL/TLS versions. If needed, create a new
decryption policy rule for a specific use
case of your NGFW causing this issue.

Client and server version mismatch Description: The sender was unable to
negotiate an acceptable set of security
parameters with the receiver given the
available options. This is likely due to
incompatibility between the SSL/TLS versions
supported by the client and server.
RFC Information: This alert falls under the
handshake_failure error defined in RFC 5246,
which is applicable to TLSv1.1-TLSv1.3.
Related Documentation: Troubleshoot
Unsupported Cipher Suites

The troubleshooting topic

uses the "Client and decrypt
profile version mismatch" search
query. For this error, use the
(error contains ‘Client
and server version
mismatch’) query.

Remediation:
• Fix version errors.
• Configure decryption profiles that are
compatible with your sender and receiver's
SSL/TLS versions. If needed, create a new
decryption policy rule for a specific use
case of your NGFW causing this issue.

Decryption Administration 153 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Root Status “Uninspected”

In some cases, the Root Status column displays the value uninspected. Reasons why the NGFW
might not inspect the root status include:
• Session resumption
• A decryption policy rule with an action of no-decrypt controls the traffic
• A decryption failure occurs before the NGFW inspects the server certificate
Filter the decryption log (root_status eq uninspected) and (tls_version eq
TLS1.3) to see decryption sessions with a root status of "uninspected."

Decryption Administration 154 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Create Decryption Reports

Where Can I Use This? What Do I Need?

• Depending on the products you're using, you

• need at least one of...
• For :
A Prisma Access license and Cloud
Services plugin for
If you're using a , no other requirements.

You can create custom reports for decryption events based on decryption log fields and custom
templates. Select log fields to include in custom reports and select templates to refine the log
query. You can schedule the reports to generate immediately (on demand) or on schedule (each
night). Creating decryption reports help you “keep a pulse” on your network, validate policy
rules, and decide where to focus your attention when maintaining or troubleshooting decryption
activity.
For information about custom report options and considerations, see Custom Reports.
STEP 1 | Select Monitor > Manage Custom Reports.

STEP 2 | Add a custom report.

Decryption Administration 155 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

STEP 3 | To configure the decryption log fields to use in the custom report, select Decryption as the
Database.

The Available Columns list changes to match the columns available in the decryption log.
Select and add the columns (information) that you want to include in the custom report. If you
don’t want to refine the custom report any further, click OK to generate the report.

STEP 4 | Under Database, select Scheduled to run a report each night. The report is available for
viewing in the Reports column on the side.

To generate a scheduled custom report using logs stored in Strata Logging Service on
the Panorama™ management server, install a Cloud Service plugin 1.8 or later release
on the server.

STEP 5 | (Optional, PAN-OS 10.0 and Later) Refine the output of the report using the Query Builder
or predefined templates.
To build a query, specify the following and click Add. Repeat as needed to construct the full
query.
• Connector—Choose the connector (AND or OR) to precede the expression you are adding.
• Negate—Select the check box to interpret the query as a negation. If, for example, you
choose to match entries from the last 24 hours that originate from the untrust zone, the

Decryption Administration 156 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

negate option causes a match on entries that are not from the past 24 hours and do not
originate from the untrust zone.
• Attribute—Choose a data element. The available options depend on the choice of database.
• Operator—Choose the criterion to determine whether the attribute applies (such as =). The
available options depend on the choice of database.
• Value—Specify the attribute value to match.
To select a template to filter the report output, click Load Template and select from the four
decryption templates:

The Query column shows the filter query that each template represents. Load the desired
query and then click OK to save the custom report.

STEP 6 | To test the report settings, select Run Now. Modify the settings as required to change the
information that displays.

STEP 7 | View the custom reports.

1. Select Monitor > Reports.
2. Select Custom Reports from the list of report types.
3. Select a report to view. The reports page then displays the report for the previous day.
To view reports for other days, select a date in the calendar below the report types. If you
select a report in another section, the date selection resets to the current date.
4. To view a report offline, export the report to PDF, CSV, or XML formats. Click Export to
PDF, Export to CSV, or Export to XML, then print or save the file.

Decryption Administration 157 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

Configure Decryption Port Mirroring

Where Can I Use This? What Do I Need?

• All deployments, including those funded Decryption Port Mirroring license

by software NGFW credits

Before you configure Decryption Port Mirroring, you must obtain a Decryption Port Mirroring
license for each Next-Generation Firewall (NGFW) that will forward decrypted traffic. The license
is free of charge and does not expire. Install each license on its respective NGFW, and then
complete the configuration steps for your management platform.
Important Considerations
We recommend consulting corporate counsel before enabling this feature in a production
environment. Note the following:
• Certain countries regulate how you decrypt, inspect, store, or otherwise use SSL/TLS traffic.
User consent might be required to mirror traffic.
• Malicious users with administrative access to the NGFW could potentially harvest sensitive
information (such as usernames, passwords, social security numbers, and credit card numbers)
submitted through encrypted channels.
Request a Decryption Port Mirroring license.
1. Log in to the Customer Support Portal.
2. Select Products > Assets, and then locate the NGFW you want to license.
3. In the Actions column for that NGFW, select Licenses & Subscriptions.
4. On the Licenses & Subscriptions page, select Activate License.
5. For Activation Types, select Activate Feature License.
6. For Activate Feature License, select Decryption Port Mirror.
7. Review the legal notice, and then click Agree and Submit.
The license is now active and displays in the Cloud Delivered Security Services list.
8. (Optional) Repeat these steps for additional NGFWs.
Install the license on an NGFW.
1. Log in to the web interface.
2. Select Device > Licenses.
3. In the License Management section, click Retrieve license keys from license server.
4. Reboot the NGFW.
1. Select Device > Setup > Operations.
2. In the Device Operations section, click Reboot Device.
3. Click Yes to confirm.
Verify that the license is active on the NGFW.

Decryption Administration 158 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

• On the NGFW web interface:

1. Select Device > Licenses.
2. In the License Management section, locate the Decryption Port Mirror box, and then verify
the Active field displays Yes.

• On Strata Cloud Manager:

1. Select System Settings > Device Management > Cloud Managed Devices.
2. In the Actions column for the NGFW, select Fetch Licenses Info.
3. Verify that the License Installed On Device list includes Decryption Port Mirror and that the
License Status is OK.
• Strata Cloud Manager
• PAN-OS & Panorama

Configure Decryption Port Mirroring (Strata Cloud Manager)

STEP 1 | Log in to Strata Cloud Manager.

STEP 2 | Configure an Ethernet interface for decryption mirroring.

1. Select Configuration > NGFW and Prisma Access > Device > Interfaces > Ethernet.
2. Select a Configuration Scope.
Select an NGFW or an entire folder (for example, All Firewalls) from your Folders or a
snippet from your Snippets to target your configuration.
3. Select an Ethernet interface or click Add Interface > Interface.

If you configure an interface in the folder or snippet scope, Strata Cloud

Manager pushes the configuration only to NGFWs that have the corresponding
interface slot available. For example, if you configure Ethernet 1/5 in the folder
scope and the NGFW associated with the folder has only four interface slots, the
push to the NGFW fails.
4. (New Interface only) Enter a descriptive Interface Name, such as all-ngfw-decrypt-
mirror.
5. Select a Default Interface Assignment.
6. For Interface Type, select Decrypt Mirror.
7. Leave the Link Settings set to auto.
8. Save the interface.

Decryption Administration 159 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

STEP 3 | Enable forwarding of decrypted traffic.

Superuser permissions are required.

For an NGFW with a single virtual system:

Strata Cloud Manager does not support decryption mirroring for NGFWs with multiple
virtual systems.

1. Select Configuration > NGFW and Prisma Access > Device > Device Setup > Content-
ID.
2. Customize the Content-ID Settings, and then select Allow forwarding of decrypted
content.
3. Save the settings.

STEP 4 | Enable mirroring of decrypted traffic.

1. Select Configuration > Security Services > Decryption.
2. Select a Decryption Profile or click Add Profile to create a new one.

Only reuse a profile if you want traffic defined in the decryption policy rules
associated with that profile to be mirrored. If you plan to configure a new
decryption policy rule, create a new decryption profile.
3. In the Decryption Mirroring section, select an Interface.

Selecting an interface that is already in use causes commits to fail.

4. Specify whether to mirror decrypted traffic before or after policy enforcement.

• By default, Forwarded Only is not selected. The NGFW mirrors all decrypted traffic
to the interface before the Security policy rule lookup. This allows you to replay
events and analyze traffic that generates a threat or triggers a drop.
• To mirror decrypted traffic only after Security policy enforcement, select Forwarded
Only. The NGFW only mirrors allowed traffic. Use this option if you're forwarding
traffic to threat detection devices, such as a data loss prevention (DLP) device or an
intrusion prevention system (IPS).
5. Save the profile.

Decryption Administration 160 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

STEP 5 | Apply the decryption profile to a decryption policy rule.

This rule defines the traffic that the NGFW mirrors.
1. Select Configuration > Security Services > Decryption.
2. In the Decryption Policies section, select an existing decryption policy rule or click Add
Rule to create a new rule.
Make sure the Action is set to Decrypt.
3. In the Action and Advanced Inspection tab, set Decryption Profile to the profile you
configured earlier.
4. Save the rule.

STEP 6 | Push your configuration changes.

Select Push Config > Push.

STEP 7 | Verify the settings applied to your NGFWs.

For example, if your Configuration Scope is set to All Firewalls, switch to the scope for a
specific NGFW to verify that the configured settings were inherited correctly. Alternatively,
log in to an individual NGFW web interface to view these settings locally.

Configure Decryption Port Mirroring (PAN-OS & Panorama)

STEP 1 | Log in to the NGFW web interface.

STEP 2 | Forward decrypted traffic.

Superuser permission is required to perform this step.

On an NGFW with a single virtual system:

1. Select Device > Setup > Content-ID.
2. Enable Allow forwarding of decrypted content.
3. Click OK.
On an NGFW with multiple virtual systems:
1. Select Device > Virtual Systems.
2. Select a Virtual System, or Add a new one.
3. Enable Allow forwarding of decrypted content.
4. Click OK.

Decryption Administration 161 ©2026 Palo Alto Networks, Inc.

Monitor Decryption

STEP 3 | Enable an Ethernet interface for decryption mirroring.

1. Select Network > Interfaces > Ethernet.
2. Select an interface. A dialog with various settings appears.
3. For Interface Type, select Decrypt Mirror.

This interface type appears only if you have installed the Decryption Port
Mirroring license.
4. Click OK.

STEP 4 | Enable mirroring of decrypted traffic.

1. Select Objects > Decryption Profile, and then select a profile or Add a new one.
2. In the Decryption Mirroring section, select an Interface.
The drop-down list contains only Ethernet interfaces of the Decrypt Mirror type.
3. Specify whether to mirror traffic before or after policy enforcement.
• By default, Forwarded Only is clear. The NGFW mirrors all decrypted traffic to the
interface before the Security policy rule lookup. This allows you to replay events and
analyze traffic that generates a threat or triggers a drop.
• To mirror decrypted traffic only after Security policy enforcement, select Forwarded
Only. The NGFW only mirrors allowed traffic. Use this option if you're forwarding
traffic to threat detection devices, such as a data loss prevention (DLP) device or an
intrusion prevention system (IPS).
4. Click OK.

STEP 5 | Attach the decryption profile to a decryption policy rule.

The NGFW mirrors traffic that matches this rule.
1. Select Policies > Decryption.
2. Select an existing decryption policy rule, or Add a new rule.
3. In the Options tab, set the Action to Decrypt.
4. For Decryption Profile, select the profile you modified (or created) earlier.
5. Click OK.

STEP 6 | Commit your changes.

Decryption Administration 162 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption
Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Troubleshooting and monitoring your Decryption deployment go hand-in-hand. Various

monitoring tools provide visibility into TLS traffic, helping you identify, diagnose, and resolve
decryption issues quickly and easily. For example, Application Command Center (ACC) widgets
provide details about successful and unsuccessful decryption activity in your network, including
decryption failures. For detailed information about specific SSL or TLS traffic and sessions, you
can view decryption logs. Your troubleshooting process could involve the following steps assisted
by the use of these tools:
• Gather Information. What is the issue? What do you expect to see that you're not? Is this issue
reproducible? When does this occur? You can use various tools to investigate and even look
back at your decryption policy rules. How would you know when things are functioning as
expected? Is it something you'd see in the logs.
• Determine the most probable cause. Are the most common problems–for example, incomplete
certificate chains and unsupported cipher suites, at play?
• Try the actions that seem the most relevant. Eliminate issues by process of elimination.
• Write down what you've done and the results you found. This will help you if you need to
work with support or if someone else encounters the same problem.
From weak protocols, unsupported cipher suites to incomplete certificate chains and revoked
certificates, the tools, actions, and resources outlined here will help you troubleshoot and remedy
all kinds of decryption errors you may encounter.
The general troubleshooting methodology is to start with Application Command Center
(ACC) widgets (if applicable) to identify traffic that causes decryption issues. Next, investigate
decryption logs or generate reports (if applicable) to drill down into details and gain context about
that traffic. With the additional context, you can take a more targeted approach and diagnose
issues more accurately. Understanding decryption issues and their causes enables you to make an
informed decision / decide the most appropriate way to fix an issue.
Common Decryption Fixes include:
• Modifying Decryption policy rules. The policy rule defines the traffic that the rule affects, the
action taken on that traffic, log settings, and the Decryption profile applied to the traffic.
• Modifying Decryption profiles, which define acceptable protocols and algorithms for the traffic
that a Decryption policy rule controls plus failure checks, unsupported mode checks for items
such as unsupported ciphers and versions, certificate checks, and more.
• Add sites that break decryption for technical reasons, such as certificate pinning or incomplete
certificate chains, to the SSL Decryption Exclusion List.

163
Troubleshoot Decryption

• Evaluate security decisions about which sites your employees, customers, and partners
really need to access and which sites you can block if they use weak decryption protocols or
algorithms.

If you think you've fixed the issue, test that what you saw in the beginning is no longer
there. Test that you haven't disrupted or caused another issue. When you cannot
reproduce an issue and the expected functionality is returned, you have likely fixed the
issue. Continue monitoring your deployment to make sure that you have not inadvertently
affected another component or system, decryption or not.

Contacting support should be a last resort and only if you are unable to pinpoint or resolve the
issue. However, by completing the above steps, you should be able provide information to assist
support in their investigation.

Additional Resources
• Monitor Decryption chapter to gain familiarity with monitoring tools and how to use them
• Decryption Log Errors and Error Indexes describes the types of errors you may encounter and
potential remedies.

Decryption Administration 164 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

Investigate Reasons for Decryption Failure

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

The most common reasons for decryption failures are TLS protocol errors, cipher version errors
(client and server version mismatches and client and Decryption profile version mismatches), and
certificate errors. To investigate decryption errors, start with the Application Command Center
(ACC) to identify failures and then go to the Decryption logs to drill down into details.
For additional information about these errors and possible remediation, see Decryption Log
Errors, Error Indexes, and Bitmasks.
• Strata Cloud Manager
• PAN-OS & Panorama

Investigate Decryption Failures (Strata Cloud Manager)

STEP 1 | Select Log Viewer, and then select Firewall/Decryption to drill down into the decryption
logs.

STEP 2 | Use the query Error Index = 'Certificate' to view all decryption sessions that
experienced certificate errors.
The Error column shows the reason for the certificate error. To filter for all decryption sessions
that had the same error, click the error message to add it to the query and then execute the
query. For example, to find all errors based on receiving a fatal alert from the client, clicking
the error produces the query (Error Index = Certificate) AND (Error Message
= ‘Received fatal alert CertificateUnknown from client’).
To filter for the certificate errors that a specific host received, add that SNI to the
query instead of adding error message text. For example, to find all certificate errors for
[Link], use the query (Error Index = 'Certificate') AND (Server
Name Indication = ‘[Link]’).
The Error column shows the specific reason for each certificate error associated with
[Link].
Once you know the reason for the certificate issue that caused the decryption failure, you can
address it. For example, if the certificate chain is incomplete, you can repair the incomplete
certificate chain. If a certificate is expired, you can notify the site administrator or create a
policy-based exception if you need to access the site.

Investigate Decryption Failures (PAN-OS)

Decryption Administration 165 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

STEP 1 | Begin your investigation at ACC > SSL Activity and look at the Decryption Failure Reasons
widget.

In this example, we investigate certificate errors. You can use the same process to investigate
version and protocol errors.

STEP 2 | Click the green bar next to Certificate to see which hosts (SNIs) experienced certificate
errors and see a list of hosts that experienced the largest number of certificate errors.

Decryption Administration 166 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

STEP 3 | Go to Monitor > Logs > Decryption to drill down into the logs.
Use the query (err_index eq Certificate) to filter the Decryption logs to view all
Decryption sessions that experienced certificate errors.

The Error column shows the reason for the certificate error. To filter for all Decryption
sessions that had the same error, click the error message to add it to the query and then
execute the query. For example, to find all errors based on receiving a fatal alert from the
client, clicking the error produces the query (err_index eq Certificate) and (error
eq ‘Received fatal alert CertificateUnknown from client’):

To filter for the certificate errors that a specific host received, add that SNI to the
query instead of adding error message text. For example, to find all certificate errors for
[Link] use the query (err_index eq Certificate) and (sni eq
‘[Link]’):

The Error column shows the specific reason for each certificate error associated with
[Link].
Once you know the reason for the certificate issue that caused the decryption failure, you
can address it. For example, if the certificate chain is incomplete, you can repair the certificate

Decryption Administration 167 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

chain. If a certificate is expired, you can notify the site administrator or create a policy-based
exception if you need to access the site.

Decryption Administration 168 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

Identify Weak Protocols and Cipher Suites

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Weak TLS protocols and weak cipher suites (encryption algorithms, authentication algorithms, key
exchange algorithms, and negotiated EC curves) weaken your security posture and are easier for
bad actors to exploit than strong TLS protocols and strong cipher suites.
Five fields in the Decryption log entries show the protocol and cipher suites for a decryption
session:

Track down old, vulnerable TLS versions and cipher suites so that you can make informed
decisions about whether to allow connections with servers and applications that may compromise
your security posture.
The examples in this topic show how to:
• Identify traffic that uses less secure TLS protocol versions.
• Identify traffic that uses a particular key exchange algorithm.
• Identify traffic that uses a particular authentication algorithm.
• Identify traffic that uses a particular encryption algorithm.
These examples show you how to use the decryption troubleshooting tools in various ways so
that you can learn to use them to troubleshoot any decryption issues you may encounter.

You can use Wireshark or other packet analyzers to double-check whether the client
or the server caused an issue, TLS client and server versions, and other cipher suite
information. This can help analyze version mismatches and other issues.

• Strata Cloud Manager

• PAN-OS & Panorama

Identify Weak Protocols and Cipher Suites (Strata Cloud Manager)

Decryption Administration 169 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

Filter decryption logs to check TLSv1.0 activity details.

Decryption logs show successful TLS activity only if you select the Log Successful TLS
Handshakes option in a decryption policy rule. If this option is disabled, you can’t see
this information.

1. Select Log Viewer, and then select Firewall/Decryption.

2. Use the query (TLS Version = 'TLS1.0') AND (Error Index = 'None') to
show successful TLSv1.0 decryption sessions.
The decryption logs show us that the name of the decryption policy rule that controls
the traffic. Now, we know the site that uses TLSv1.0 and can check the decryption policy
rule to find the decryption profile that controls the traffic and learn why the traffic is
allowed.
3. Find the decryption profile that controls the traffic to learn why the traffic is allowed.
1. Select Configuration > NGFW and Prisma Access > Security Services >
Decryption, and search for the decryption policy rule you identified earlier.
2. Scroll to the Profile column of the decryption policy rule. Alternatively, you can select
the rule to open it. Then, under Action and Advanced Inspection, find the Decryption
Profile.
Example: The decryption profile associated with the policy rule is old TLS versions
support.
4. Check the Protocol Versions that the decryption profile allows.
• Under Decryption Profiles, select the profile identified earlier.
• Under SSL/TLS Decryption, look at the Protocol Min Version and Protocol Max
Version.
Example: The profile allows TLSv1.0 traffic.
5. Decide if want to allow or block access to the website.
Ask questions like "Do you need access for business purposes?"
Another common scenario that results in the NGFW allowing traffic that uses less secure
protocols is when that traffic is not decrypted. When you filter the decryption log for
TLSv1.0 traffic, if the Proxy Type column contains the value No Decrypt, then a No
Decryption policy controls the traffic, so the NGFW doesn't decrypt or inspect it. If you

Decryption Administration 170 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

don’t want to allow the weak protocol, modify the decryption profile so that it blocks
TLSv1.0 traffic.
There are many ways you can filter decryption logs to find applications and sites that use
weak protocols. For example:
• Instead of filtering only for successful TLSv1.0 handshakes, filter for both successful
and unsuccessful TLSv1.0 handshakes using the query TLS Version = 'TLS1.0'.
• Filter only for unsuccessful TLSv1.0 handshakes using the query (TLS Version =
'TLS1.0') AND (Error Index = 'None').
• Filter for all less secure protocols (TLSv1.1 and earlier) using the query TLS Version
<='TLS1.1'.
If you want to filter the logs for other TLS versions, simply replace TLS1.0 or
TLS1.1 with another TLS version.

Decide what action to take for sites that use weak TLS protocols.
• If you don’t need to access the site for business purposes, the safest action is to block
access to the site by editing the decryption policy rule and decryption profile that control
the traffic. The decryption log Policy Name column provides the policy name and the
decryption policy shows the attached decryption profile (Action and Advanced Inspection
tab).
• If you need to access the site for business purposes, consider creating a decryption policy
rule and decryption profile that apply only to that site (or to that site and other similar sites)
and block all other traffic that uses less secure protocols.

Identify traffic that uses less secure key exchange algorithms, for example, RSA.
1. Filter decryption logs using the query TLS Key Exchange = RSA:
Select Log Viewer, and then select Firewall/Decryption.
From the Policy Name column in the log, we see that the No Decrypt decryption
policy rule controls most of the traffic that uses RSA key exchanges and can infer that
the NGFW does not decrypt the traffic and allows it without inspection. Because the
traffic isn’t decrypted, the NGFW can’t identify the application and lists it as ssl. If you
don’t want to allow traffic that uses RSA key exchanges, modify the decryption profile
attached to the decryption policy that controls the traffic.
You can add to the query to further filter the results for a particular SNI or application
that you saw in the first decryption log query.
2. Decide what action to take for traffic that uses less secure key exchange algorithms.
Block access to sites that use less secure key exchange protocols unless you need to
access them for business purposes. For those sites, consider creating a decryption policy
rule and decryption profile that applies only to that site (or to that site and other similar
sites), and block all other traffic that uses less secure key exchange algorithms.

Decryption Administration 171 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

Use the decryption logs to identify sessions that use older, less secure authentication
algorithms.
Filter the decryption log to identify older, less secure authentication algorithms. For example,
to identify all sessions that use the SHA1 algorithm, use the query TLS Auth = SHA.
You can add to the query to further drill down into the results. For example, you can add a
particular SNI, a key exchange version (such as filtering for SHA1 sessions that also use RSA
key exchanges), a TLS version, or any other metric found in a decryption log column.

Use the decryption logs to identify sessions that use a particular encryption algorithm.
For example, to identify all sessions that use the AES-128-CBC encryption algorithm, use
the query TLS Encryption Algorithm = AES_128_CBC. You can add to the query to
further drill down into the results.
Examples of queries to find other older encryption algorithms include:
TLS Encryption Algorithm = DES_CBC, TLS Encryption Algorithm =
3DES_EDE_CBC, and TLS Encryption Algorithm = DES40_CBC.

Use this methodology and the log Query Builder to create queries to investigate negotiated
ECC curves and any other information you find in the decryption logs.

Identify Weak Protocols and Cipher Suites (PAN-OS)

Decryption Administration 172 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

TLS Protocols—Identify traffic that uses older, less secure versions of the TLS protocol so that
you can evaluate whether to allow access to servers and applications that use weak protocols.
1. Check the Application Command Center (ACC > SSL Activity > Successful TLS Version
Activity) for applications that use weak protocols and to get an overall view of activity.

The majority of successful TLS activity in this example is TLSv1.2 and TLSv1.3 activity.
However, there are a few instances of allowed TLSv1.0 traffic. Let’s click the number 49

Decryption Administration 173 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

to drill down into the TLSv1.0 activity and see which applications are making successful
TLSv1.0 connections:

We see that the NGFW allowed web-browsing traffic over a TLSv1.0 connection. To
gain insight into what that TLSv1.0 web-browsing traffic is and why it’s allowed, we look
at the decryption logs.
2. Filter the decryption logs by successful TLSv1.0 activity.
To show successful TLSv1.0 decryption sessions, use the (tls_version eq TLS1.0)
and (err_index eq ‘None’) query.

Decryption logs show successful TLS activity only if you select the Log
Successful TLS Handshakes option in a decryption policy rule. If this option is
disabled, you can’t see this information.

The decryption logs show us that the decryption policy rule that controls the traffic is
Inner Eye and that the name of the host is [Link]. Now, we know the site

Decryption Administration 174 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

that uses TLSv1.0 and we can check our decryption policy rules (Policies > Decryption)
to find the decryption profile that controls the traffic and learn why the traffic is allowed:

We see that the decryption profile associated with the policy is old TLS versions
support. We check the profile (Objects > Decryption > Decryption Profile) and look at
the SSL Protocol Settings to find out exactly what traffic the profile allows:

The profile allows TLSv1.0 traffic. The next thing to do is to decide if you want to allow
access to the site (do you need access for business purposes?) or block access.
Another common scenario that results in the NGFW allowing traffic that uses less secure
protocols is when that traffic isn’t decrypted. When you filter the decryption log for
TLSv1.0 traffic, if the Proxy Type column contains the value No Decrypt, then a no-

Decryption Administration 175 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

decryption policy rule controls the traffic, so the NGFW does not decrypt or inspect it.
If you don’t want to allow the weak protocol, modify the decryption profile so that it
blocks TLSv1.0 traffic.
There are many ways you can filter decryption logs for applications and sites that use
weak protocols, for example:
• Instead of filtering only for successful TLSv1.0 handshakes, filter for both successful
and unsuccessful TLSv1.0 handshakes using the query (tls_version eq
TLS1.0).
• Filter only for unsuccessful TLSv1.0 handshakes using the query (tls_version eq
TLS1.0) and (err_index neq ‘None’).
• Filter for all less secure protocols (TLSv1.1 and earlier) using the query
(tls_version leq tls1.1).
If you want to filter the logs for other TLS versions, simply replace TLS1.0 or TLS1.1
with another TLS version.
3. Decide what action to take for sites that use weak TLS protocols.
• If you don’t need to access the site for business purposes, the safest action is to block
access to the site by editing the decryption policy rule and decryption profile that
control the traffic. The decryption log Policy Name column provides the policy name
and the decryption policy rule shows the attached decryption profile (Options tab).
• If you need to access the site for business purposes, consider creating a decryption
policy rule and decryption profile that applies only to that site (or to that site and
other similar sites), and block all other traffic that uses less secure protocols.

Decryption Administration 176 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

Key Exchange—Identify traffic that uses less secure key exchange algorithms.
1. Check the Application Command Center (ACC) (ACC > SSL Activity > Successful Key
Exchange Activity) to see which key exchange algorithms the NGFW allows and to get
an overall view of activity.

The majority of the key exchanges use the secure ECDHE key exchange algorithm.
However, some key exchange sessions use the less secure RSA algorithm and a few use

Decryption Administration 177 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

another key algorithm. To begin investigating traffic that uses RSA key exchanges, for
example, click the number 325 to drill down into the data.

The drill-down shows the applications that use RSA key exchanges. We can also click the
SNI radio button to view the RSA key exchanges by SNI:

Decryption Administration 178 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

Armed with this information, we can go to the logs to gain more context about RSA key
exchange usage.
2. Go to the decryption logs (Monitor > Logs > Decryption)) and filter them for decryption
sessions that use the RSA key exchange using the query (tls_keyxchg eq RSA):

From the Policy Name column in the log, we see that the No Decrypt decryption policy
rule controls most of the traffic that uses RSA key exchanges and can infer that the
NGFW doesn't decrypt the traffic and allows it without inspection. Because the traffic

Decryption Administration 179 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

isn’t decrypted, the NGFW can’t identify the application and lists it as ssl. If you don’t
want to allow traffic that uses the RSA key exchange algorithm, modify the decryption
profile attached to the decryption policy rule that controls the traffic.
You can add to the query to further filter the results for a particular SNI or application
that you saw in the ACC or in the first decryption log query.
3. Decide what action to take for traffic that uses less secure key exchange algorithms.
Block access to sites that use less secure key exchange protocols unless you need to
access them for business purposes. For those sites, consider creating a decryption policy
rule and decryption profile that apply only to that site (or to that site and other similar
sites) and block all other traffic that uses less secure key exchange algorithms.

Use the decryption logs to identify sessions that use older, less secure authentication
algorithms.
Filter the decryption logs by older, less secure authentication algorithms.
For example, to identify all sessions that use the SHA1 algorithm, use the query (tls_auth
eq SHA):

You can add to the query to further drill down into the results. For example, you can add a
particular SNI, a key exchange version (such as filtering for SHA1 sessions that also use RSA
key exchanges), a TLS version, or any other metric found in a decryption log column.

Decryption Administration 180 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

Use the decryption logs to identify sessions that use a particular encryption algorithm.
For example, to identify all sessions that use the AES-128-CBC encryption algorithm, use the
query (tls_enc eq AES_128_CBC):

You can add to the query to further drill down into the results.
Examples of queries to find other older encryption algorithms include: (tls_enc eq
DES_CBC), (tls_enc eq 3DES_EDE_CBC), and (tls_enc eq DES40_CBC).

Use this methodology and the log filter builder to create queries to investigate negotiated ECC
curves and any other information you find in the decryption logs.

Decryption Administration 181 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

Troubleshoot Version Errors

Where Can I Use This? What Do I Need?

• Prisma Access (Managed by Panorama) • For Prisma Access (Managed by

• NGFW (Managed by PAN-OS or Panorama):
Panorama) A Prisma Access license
Cloud Services plugin for Panorama
• If you're using a NGFW (Managed by PAN-
OS or Panorama), no other requirements.

Version errors arise when there are mismatches between the TLS protocol versions that the client
and server use or between the TLS protocol versions that the client and the Decryption profile
applied to the traffic use. The error messages includes bitmask values that identify the supported
client and Decryption profile versions. You can use these values to identify the cipher the client
tried to use and the cipher values that the Decryption profile supports. The CLI command to
convert version error bitmasks is: debug dataplane show ssl-decrypt bitmask-
version <bitmask-value>. For more information and remediation, see Decryption Log
Errors and Error Indexes.
Key Steps for Converting Bitmask Values and Turning Them Into Something Useful
1. Filter the Decryption logs for version errors using a query.
2. Plug the bitmask value into the appropriate CLI command to identify the protocol versions that
caused the error.
3. Use the cipher information to update the Decryption profile if you want to allow access to the
site in question.

Decryption Administration 182 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

STEP 1 | Identify version errors in the decryption logs.

1. Select Monitor > Logs > Decryption.
2. Filter decryption logs using the following queries:
• To find all instances where the error is related to protocol versions: (err_index eq
Version). The highlighted values are bitmask values.
Error Index = Version

• To find all instances where the protocol versions supported by the client and in the
Decryption profile attached to the policy rule don't match: (error contains
‘Client and decrypt profile mismatch’).
Error contains 'client and decrypt profile version mismatch'

You can filter decryption logs in many ways.

For example, to see only TLSv1.3 version errors, specify the error index and the TLS
version you're looking for in the query as follows: (err_index eq Version) and
(tls_version eq TLS1.3).

To find all decryption sessions that experienced the same error, click an error message to add it
to the query and remove the original query, for example:

Decryption Administration 183 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

The hexadecimal codes or bitmasks identify the exact version that the client supports and the
exact version that the Decryption profile supports.

STEP 2 | Log in to the CLI to look up the bitmask values.

To identify the TLS versions that a bitmask corresponds to, use the debug dataplane show
ssl-decrypt bitmask-version <bitmask-value> CLI command.
Example screens of this lookup:
• Example 1 (first screenshot)
The version errors in the first screenshot (the same errors for all three sessions) show an
issue with a client and Decryption profile mismatch. The version supported by the client
is represented by the 0x08 bitmask and the version supported in the Decryption profile
bitmask is 0x70.
1. admin@vm1>debug dataplane show ssl-decrypt bitmask-version 0x08
TLSv1.0

This output shows that the client supports only TLSv1.0.

2. admin@vm1>debug dataplane show ssl-decrypt bitmask-version 0x70
TLSv1.1
TSLv1.2
TLSv1.3

This output shows that the Decryption profile supports TLSv1.1, TLSv1.2, and TLSv1.3,
but not TLSv1.0. Now you know the issue is that the client only supports an older

Decryption Administration 184 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

version of the TLS protocol and the Decryption profile attached to the decryption policy
rule that controls the traffic does not allow TLSv1.0 traffic.
• Example 2 (third screenshot)
The version error in the second screenshot shows a different issue: a client and server
version mismatch. The error indicates the supported client bitmask as 0x20:

admin@vm1> debug dataplane show ssl-decrypt bitmask-version 0x20

TLSv1.2

The output shows that the client supports only TLSv1.2, which means that the server
doesn't support this version. The server might only support TLSv1.3 or it might support only
TLSv1.1 or lower (less secure protocols).

STEP 3 | Decide what action to take.

How you fix this error depends on the TLS versions supported by the client and server and
your business needs.
• Evaluate if you need access to the server for business or another important purpose.
• Confirm the TLS versions that the server supports. You can use Wireshark or another
packet analysis tool to find out which TLS versions the server supports.
• You could update the client or server to support a stronger version.
• If the client only supports a weaker TLS version, and cannot support a more secure protocol,
as in Example 1, you can:
• Let the NGFW continue to block the traffic.
• (Not Recommended) Update the Decryption profile to allow certain TLS traffic.
Continue to step 4. This option allows traffic of a specific TLS version when it matches
the decryption policy rules that the profile is attached to, which is why it's not
recommended.

Don't allow access to all servers that use less secure TLS versions. Create more
specific rules for cases like this.

This may be a good course of action in a case like Example 2, where the server
supports a more secure TLS protocol than the client. Then, you'd be updating the
client so that it accepts a more secure TLS version, which is good for security.
• (Most Secure option) Configure a Decryption profile that allows the weaker TLS version,
but apply it to a decryption policy rule for the particular server that controls the sites,
user, device, or source address (and to any similar users, devices, or source addresses so
that one policy rule and profile control all of this traffic) that must use this server.

Decryption Administration 185 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

STEP 4 | Identify and modify the Decryption profile associated with the policy rule that controls the
session traffic.
1. Identify the decryption policy rule that control the session traffic.
1. Check the Policy Name column in the log (or click the magnifying glass next to a
Decryption log entry to see the information in the General section of the Detailed Log
View).
2. Select Policies > Decryption. Then, select the policy rule with the Policy Name above.
In the examples, the policy rule is Big Brother.
2. Identify the Decryption profile.
Select the Options tab. Decryption profile displays the name of the Decryption profile.
3. Edit the protocol versions supported in the Decryption profile.
• Select Objects > Decryption > Decryption Profile, and select the appropriate
Decryption profile.
• Select SSL Decryption > SSL Protocol Settings, and then select the Min Version and
Max Version that you need.
• Click OK.

STEP 5 | Commit your changes.

Decryption Administration 186 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

Troubleshoot Unsupported Cipher Suites

Where Can I Use This? What Do I Need?

• Prisma Access (Managed by Panorama) • For Prisma Access (Managed by

• NGFW (Managed by PAN-OS or Panorama):
Panorama) A Prisma Access license
Cloud Services plugin for Panorama
• If you're using a NGFW (Managed by PAN-
OS or Panorama), no other requirements.

Cipher errors are unsupported cipher errors where at least one of the following is true:
• The client tries to negotiate a cipher that the NGFW supports but that the Decryption profile
applied to the traffic doesn’t support.
• The client tries to negotiate a cipher that the NGFW does not support.
• (Rare) SSL Inbound Inspection is enabled and the server’s capabilities don’t match the
Decryption profile settings.
• The error message includes the supported client cipher bitmask value and the supported
Decryption profile cipher bitmask value. You can use bitmask values to identify the cipher the
client tried to use and the cipher values that the Decryption profile supports.
Key Steps for Converting Bitmask Values and Turning Them Into Something Useful
1. Filter the Decryption logs for cipher errors using a query.
2. Plug the bitmask value into the appropriate CLI command to identify the cipher that caused the
error.
3. Use the cipher information to update the Decryption policy rule or Decryption profile if you
want to allow access to the site in question.
STEP 1 | Identify cipher errors in the Decryption logs.
1. Select Monitor > Logs > Decryption.
2. Filter the Decryption logs using the query (err_index eq Cipher). The highlighted
values are bitmask values. For example, let’s examine a cipher error with the Error message
Unsupported cipher. Supported client cipher bitmask: 0x80000000.
Support decrypt profile cipher bitmask 0x60f79980.

Decryption Administration 187 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

STEP 2 | Log in to the CLI to look up the bitmask values.

admin@vm1>debug dataplane show ssl-decrypt bitmask-cipher

0x80000000

CHACHA_PLY1305_SHA256

This output shows that client tried to negotiate a cipher that the NGFW supports (if the
bitmask is all zeros (0x0000000, then the client tried to negotiate a cipher that the NGFW
doesn’t support):

admin@vm1>debug dataplane show ssl-decrypt bitmask-cipher

0x80000000
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS13_WITH_AES_256_GCM_SHA384
TLS13_WITH_AES_128_GCM_SHA256

This output shows that the Decryption profile that controls the traffic supports many ciphers,
but does not support the cipher the client is trying to use.
To fix this issue so that the NGFW allows and decrypts the traffic, you need to add support for
the missing cipher to the Decryption profile.

STEP 3 | Identify the decryption policy rule and profile that controls the session traffic.
1. Check the Policy Name for a decryption log entry (or click the magnifying glass to see
the information in the General section of the Detailed Log View).
2. Select the policy rule (ObjectsPoliciesDecryption), and open the rule. Then, on the
Options tab, go to the Options and find the value under Decryption Profile.
3. Select Objects > Decryption > Decryption Profile, and select the appropriate Decryption
profile.
4. Update the Key Exchange Algorithms, Encryption Algorithms, and Authentication
Algorithms fields as needed.
5. Click OK to save the profile.
Select the CHACHA20-POLY1305 encryption algorithm option (the Max Version
setting of Max means that the profile already supports TLSv1.3 and the Authentication

Decryption Administration 188 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

Algorithm setting already includes SHA256, so only the Encryption Algorithm support
was missing).

If the NGFW does not support a cipher suite and you need to allow the traffic
for business purposes, create a decryption policy rule and profile that applies
only to that traffic. In the Decryption profile, disable the Block sessions with
unsupported cipher suites option.

STEP 4 | Commit the configuration.

After you commit the configuration, the Decryption profile supports the missing cipher and the
decryption sessions for the traffic succeed.

Decryption Administration 189 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

Identify Untrusted CA Certificates

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Blocking access to sites with untrusted CA certificates and certificates self-signed by an untrusted
root CA is a best practice because sites with untrusted CAs may indicate a man-in-the-middle
attack, a replay attack, or other malicious activity.
• Strata Cloud Manager
• PAN-OS & Panorama

Identify Untrusted CA Certificates (Strata Cloud Manager)

STEP 1 | Block sessions with untrusted issuers in the decryption profile for SSL Forward Proxy.
When you block sessions with untrusted issuers in the decryption profile, the decryption log
records the error.
1. Select Configuration > NGFW and Prisma Access > Security Services > Decryption.
2. Under Decryption Profiles, select or Add a new profile, and then select the Block sessions
with untrusted issuers option.

STEP 2 | Filter decryption logs to identify sessions that failed due to revoked certificates.
1. Select Log Viewer > Firewall/Decryption.
2. Use the query Error Message = ‘Untrusted issuer CA’.

STEP 3 | (Optional) Double-check the certificate expiration date at the Qualys SSL Labs site.
Enter the hostname of the server (Server Name Identification column of the decryption log) in
the Hostname field, and then Submit it to view certificate information for the host.

Identify Untrusted CA Certificates (PAN-OS)

Decryption Administration 190 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

STEP 1 | Block sessions with untrusted issuers in the Forward Proxy Decryption profile.
When you block sessions with untrusted issuers in the Decryption profile, the Decryption logs
log the error.
Select Objects > Decryption > Decryption Profiles. Then, select a profile to modify or create a
new profile.

STEP 2 | Filter the log to identify sessions that failed due to revoked certificates using the query
(error eq ‘Untrusted issuer CA’).

STEP 3 | (Optional) Double-check the certificate expiration date at the Qualys SSL Labs site.
Enter the hostname of the server (Server Name Identification column of the Decryption log) in
the Hostname field and Submit it to view certificate information for the host.

Decryption Administration 191 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

Repair Incomplete Certificate Chains

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Not all websites send their complete certificate chain even though the RFC 5246 TLSv1.2
standard requires authenticated servers to provide a valid certificate chain leading to an
acceptable certificate authority (CA). When you enable decryption and apply a Forward Proxy
Decryption profile that blocks sessions with untrusted issuers to a Decryption policy rule, if an
intermediate certificate is missing from the certificate list the website’s server presents to the
NGFW, the NGFW can’t construct the certificate chain to the top (root) certificate. In these cases,
the NGFW presents its Forward Untrust certificate to the client because trust can't be established
without the missing intermediate certificate.

The NGFW also presents its Forward Untrust certificate if traffic matches a Decryption
profile that allows sessions with untrusted issuers.

The NGFW only has root certificates in its Default Trusted Certificate Authorities store.

If a website you need to communicate with for business purposes has one or more missing
intermediate certificates and the Decryption profile blocks sessions with untrusted issuers, then
you can find and download the missing intermediate certificate and install it on the NGFW as
a trusted root CA so that the NGFW trusts the site’s server. (The alternative is to contact the
website owner and ask them to configure their server so that it sends the intermediate certificate
during the handshake.)

If you allow sessions with untrusted issuers in the Decryption profile, the NGFW can
establish sessions even if the issuer is untrusted. The NGFW presents the Forward Untrust
certificate to the client and displays a warning message in the browser, which enables
users to accept the risk and continue to the site or not. However, it's a best practice to
block sessions with untrusted issuers for better security.

• Strata Cloud Manager

• PAN-OS & Panorama

Repair Incomplete Certificate Chains (Strata Cloud Manager)

Decryption Administration 192 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

STEP 1 | Find websites that cause incomplete certificate chain errors.

1. Filter the decryption logs for sessions that failed because of an incomplete certificate
chain.
• Select Log Viewer > Firewall/Decryption.
• In the filter field, enter the query Error Index = 'Certificate') AND
(Error Message LIKE ‘%http%’).
This query filters the logs for Certificate errors that contain the string “http”, which
finds all of the error entries that contain the CA Issuer URL (often called the URI).
The CA Issuer URL is the Authority Information Access (AIA) information for the CA
Issuer.
2. Select an entry in the Error Message column that begins “Received fatal alert
UnknownCA from client. CA Issuer URL:” followed by the URI.
The NGFW automatically adds the selected error to the query and shows the full URI
path (the full URI path may be truncated in the Error Message column).

STEP 2 | Copy and paste the URI into your browser and then press Enter to download the missing
intermediate certificate.

STEP 3 | Click the certificate to open the dialog.

Decryption Administration 193 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

STEP 4 | Open the certificate file.

STEP 5 | Select Details, and then click Copy to File....

Follow the export directions. The certificate copies to the folder you designated as your
default download folder.

Decryption Administration 194 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

STEP 6 | Import the certificate into the NGFW.

1. Select Configuration > NGFW and Prisma Access > Objects > Certificate Management.
Under Custom Certificates, select Import.
2. Browse to the folder where you stored the missing intermediate certificate and select it.
Leave the File Format as Base64 Encoded Certificate (PEM).

3. Name the certificate, specify any other options you want to use, and then click OK.

STEP 7 | When the certificate has imported, select the certificate from the Custom Certificates list to
open the Certificate Information dialog.

STEP 8 | Specify the use for the certificate.

For Certificate Use For, select Trusted Root CA, and then click Save. The imported certificate
now appears in the list of certificates.

STEP 9 | Confirm that the certificate is regarded as a Trusted Root CA Certificate.

Under Custom Certificates, select the newly imported certificate. Then, verify that the Usage
column displays Trusted Root CA Certificate.

STEP 10 | Push Config to commit the configuration.

You have now repaired the broken certificate chain. The NGFW doesn’t block the traffic
because the CA issuer is now trusted.

STEP 11 | Repeat this process for all missing intermediate certificates to repair their certificate chains.

Repair Incomplete Certificate Chains (PAN-OS)

STEP 1 | Find websites that cause incomplete certificate chain errors.
1. Filter the Decryption log to identify Decryption sessions that failed because of an
incomplete certificate chain.
In the filter field, type the query (err_index eq Certificate) and (error
contains ‘http’). This query filters the logs for Certificate errors that contain the
string “http”, which finds all of the error entries that contain the CA Issuer URL (often

Decryption Administration 195 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

called the URI). The CA Issuer URL is the Authority Information Access (AIA) information
for the CA Issuer.
2. Click an Error column entry that begins “Received fatal alert UnknownCA from client. CA
Issuer URL:” followed by the URI.

The NGFW automatically adds the selected error to the query and shows the full URI
path (the full URI path may be truncated in the Error column).

STEP 2 | Copy and paste the URI into your browser and then press Enter to download the missing
intermediate certificate.

STEP 3 | Click the certificate to open the dialog.

Decryption Administration 196 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

STEP 4 | Click Open to open the certificate file.

STEP 5 | Select the Details tab and then click Copy to File....

Follow the export directions. The certificate copies to the folder you designated as your
default download folder.

Decryption Administration 197 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

STEP 6 | Import the certificate into the NGFW.

1. Navigate to Device > Certificate Management > Certificates and then select Import.
2. Browse to the folder where you stored the missing intermediate certificate and select it.
Leave the File Format as Base64 Encoded Certificate (PEM).

3. Name the certificate, specify any other options you want to use, and then click OK.

STEP 7 | When the certificate has imported, select the certificate from the Device Certificates list to
open the Certificate Information dialog.

STEP 8 | Select Trusted Root CA to mark the certificate as a trusted root CA, and then click OK.

In Device > Certificate Management > Certificates > Device Certificates, the imported
certificate now appears in the list of certificates. Check the Usage column to confirm that the
status is Trusted Root CA Certificate.

STEP 9 | Commit the configuration.

STEP 10 | You have now repaired the broken certificate chain.

The NGFW doesn’t block the traffic because the CA issuer is now trusted. Repeat this process
for all missing intermediate certificates to repair their certificate chains.

Decryption Administration 198 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

Troubleshoot Pinned Certificates

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

Certificate pinning forces the client application to validate the server’s certificate against a known
copy to ensure that certificate really comes from the server. The intent of pinned certificates is
to protect against man-in-the-middle (MITM) attacks where a device between the client and the
server replaces the server certificate with another certificate.
Although this prevents malicious actors from intercepting and manipulating connections, it also
prevents forward proxy decryption because the NGFW creates an impersonation certificate
instead of the server certificate to present to the client. Instead of one session that connects the
client and server directly, forward proxy creates two sessions, one between the client and the
NGFW and another between the NGFW and the server. This establishes trust with the client so
that the NGFW can decrypt and inspect the traffic.
However, when a certificate is pinned, the NGFW cannot decrypt the traffic because the client
does not accept the NGFW’s impersonation certificate—the client only accepts the certificate that
is pinned to the application.
• Strata Cloud Manager
• PAN-OS & Panorama

Troubleshoot Pinned Certificates (Strata Cloud Manager)

STEP 1 | Filter the decryption logs for pinned certificates.
1. Select Log Viewer > Firewall/Decryption.
2. Use the query Error Message LIKE ‘Unknown CA’.
The application generates a TLS error code (Alert) when it fails to verify the server’s certificate.
Different applications may use different error codes to indicate a pinned certificate. The most
common error indicators for pinned certificates are UnknownCA and BadCertificate. After
running the Error Message LIKE ‘Unknown CA’ query, run the query Error Message
LIKE ‘Unknown CA’ ‘Bad Certificate’ to catch more pinned certificate errors.

You can use Wireshark or other packet analyzers to double-check the error. Look for
the client breaking the connection immediately after the TLS handshake to confirm
that it is a pinned certificate issue.

STEP 2 | Decide what to do about pinned certificates.

If you don’t need access for business purposes, you can let the NGFW continue to block
access. If you need access, then you can exclude the server from decryption by adding it to the

Decryption Administration 199 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

SSL Decryption Exclusion List. The NGFW bypasses decryption for sites on the SSL Decryption
Exclusion List. The NGFW cannot inspect the traffic, but the traffic is allowed.

Troubleshoot Pinned Certificates (PAN-OS)

STEP 1 | Filter the Decryption log (Monitor > Logs > Decryption) to find pinned certificates using the
query (error contains ‘UnknownCA’).

The application generates a TLS error code (Alert) when it fails to verify the server’s certificate.
Different applications may use different error codes to indicate a pinned certificate. The most
common error indicators for pinned certificates are UnknownCA and BadCertificate. After
running the (error contains ‘UnknownCA’) query, run the query (error contains
‘BadCertificate’) to catch more pinned certificate errors.

You can use Wireshark or other packet analyzers to double-check the error. Look for
the client breaking the connection immediately after the TLS handshake to confirm
that it is a pinned certificate issue.

STEP 2 | Decide what to do about pinned certificates.

If you don’t need access for business purposes, you can let the NGFW continue to block
access. If you need access, you can exclude the server from decryption by adding it to the SSL
Decryption Exclusion List (Device > Certificate Management > SSL Decryption Exclusion.
The NGFW bypasses decryption for sites on the SSL Decryption Exclusion List. The NGFW
cannot inspect the traffic, but the traffic is allowed.

Decryption Administration 200 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

Troubleshoot Expired Certificates

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

If you follow decryption best practices and block sessions with expired certificates in a
decryption profile for SSL Forward Proxy or No-decryption, and a server presents an expired
certificate, the Next-Generation Firewall (NGFW) blocks the session. However, if a site that
you need to access for business reasons allows its certificate to expire, connections to that site
could be blocked and you may not know why. You can use decryption logs to check for expired
certificates or certificates that will expire soon so you can be aware of the situation and take
appropriate action.
• Strata Cloud Manager
• PAN-OS & Panorama

Troubleshoot Expired Server Certificates (Strata Cloud Manager)

STEP 1 | Filter the decryption logs for expired certificates.
1. Select Log Viewer, and then select Firewall/Decryption.
2. In the search field, enter the query Error Message = ‘Expired server
certificate’.
This query identifies servers that generate Expired server certificate errors.
The NGFW blocks access to these servers because of the expired certificate.

STEP 2 | (Optional) Double-check the certificate expiration date at the Qualys SSL Labs site.
Enter the hostname of the server (Server Name Identification column of the decryption log) in
the Hostname field and Submit it to view certificate information for the host.

STEP 3 | Filter the decryption logs for certificates that expire soon.
1. Select Log Viewer, and then select Firewall/Decryption.
2. In the search field, enter a query to find upcoming certificate end dates:
Use the Time Not After parameter with a future date, for example, Time Not
After <=‘2020-01-01’.
Example: Suppose today’s date is December 1, 2024, and you want to give yourself two
months to evaluate and prepare in case sites don’t update their certificates, search for
certificates that expire by February 1, 2025 (Time Not After <=‘2025-02-01’)).
To see the exact date on which a certificate expires, look at the Certificate End Date
column in the logs.

Decryption Administration 201 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

STEP 4 | Determine the action to take for sites with expired certificates.
• If you don’t need to access the site for business purposes, the safest action is to continue to
block access to the site.
• If you need to access the site for business purposes, take one of the following actions:
• Contact the administrator of the site with the expired certificate and notify them that
they need to update or renew their certificate.
• Create a decryption policy rule that targets business-critical sites with expired
certificates and a decryption profile that allows access to sites with expired certificates.
Apply the rule exclusively to business-critical sites. As sites update their certificates,
promptly remove them from the rule.

Troubleshoot Expired Server Certificates (PAN-OS)

STEP 1 | Filter the decryption logs for expired certificates using the query (error eq ‘Expired
server certificate’).

This query identifies servers that generate Expired server certificate errors. The
NGFW blocks access to these servers because of the expired certificate.

STEP 2 | (Optional) Double-check the certificate expiration date at the Qualys SSL Labs site.
Enter the hostname of the server (Server Name Identification column of the decryption log) in
the Hostname field and Submit it to view certificate information for the host.

Decryption Administration 202 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

STEP 3 | Filter the decryption logs (Monitor > Logs > Decryption) for certificates that will expire soon
using a query that identifies upcoming certificate end dates.
For example, if today’s date is February 1, 2020, and you want to give yourself two months to
evaluate and prepare in case sites don’t update their certificates, query the decryption logs for
certificates that expire April 1, 2020 or earlier (notafter leq ‘2020/4/01’)):

The Certificate End Date column shows the exact date on which the certificate expires.

STEP 4 | Determine the action to take for sites with expired certificates.
• If you don’t need to access the site for business purposes, the safest action is to continue
blocking access to the site.
• If you need to access the site for business purposes, take one of the following actions:
• Contact the administrator of the site with the expired certificate and notify them that
they need to update or renew their certificate.
• Create a decryption policy rule that targets sites with expired certificates that you need
for business purposes. Then, create and attach a decryption profile that allows access to
sites with expired certificates. Apply the rule exclusively to business-critical sites. As sites
update their certificate, promptly remove them from the rule.

Decryption Administration 203 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

Troubleshoot Revoked Certificates

Where Can I Use This? What Do I Need?

• All deployments, including those funded No separate license required for decryption
by software NGFW credits when using NGFWs or .
• All deployments Note: The features and capabilities available
to you in depend on your active license(s).

A revoked certificate is no longer valid. It may indicate that there are security issues with a
site and that the certificate is not trustworthy, although there are also benign reasons why a
certificate may be revoked.

Don’t trust revoked certificates; enable certificate revocation checking to deny access to
sites with revoked certificates.

To drop sessions with revoked certificates and troubleshoot revoked certificates, enable
certificate revocation checking. If you don’t enable certificate revocation checking, the NGFW
doesn’t check for revoked certificates and you won’t know if a site has a revoked certificate.
• Strata Cloud Manager
• PAN-OS & Panorama

Troubleshoot Revoked Certificates (Strata Cloud Manager)

Before you begin this task, enable certificate revocation checks using OCSP and CRL if you
haven't already.
STEP 1 | Filter the decryption logs for certificate revocation errors.
1. Select Log Viewer, and then select Firewall/Decryption.
2. In the search field, enter the following query: Error Message = ‘OCSP/CRL
check: certificate revoked’.

STEP 2 | (Optional) Double-check the certificate expiration date at the Qualys SSL Labs site.
Enter the hostname of the server (Server Name Identification column of the decryption log) in
the Hostname field and Submit it to view certificate information for the host.

Troubleshoot Revoked Certificates (PAN-OS)

Decryption Administration 204 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

STEP 1 | Enable certificate revocation checking if you haven’t already enabled it.
1. Go to Device > Setup > Session > Decryption Settings.
2. Enable both OCSP and CRL certificate checking.

If you Block sessions on certificate status check timeout in the Forward Proxy
Decryption profile and are concerned that 5 seconds is not enough time and may result
in too many sessions blocked by timeouts, set the Receive Timeout (sec) to a longer
amount of time.

STEP 2 | Filter the Decryption log (Monitor > Logs > Decryption) to find certificate revocation errors
using the query (error eq ‘OCSP/CRL check: certificate revoked’).

STEP 3 | (Optional) Double-check the certificate expiration date at the Qualys SSL Labs site.
Enter the hostname of the server (Server Name Identification column of the Decryption log) in
the Hostname field and Submit it to view certificate information for the host.

Decryption Administration 205 ©2026 Palo Alto Networks, Inc.

Troubleshoot Decryption

Decryption Administration 206 ©2026 Palo Alto Networks, Inc.