Decryption Log

The Decryption Log (
) provides comprehensive information about sessions that match a Decryption policy to help you gain context about that traffic so you can accurately and easily diagnose and resolve decryption issues. The firewall does not log traffic if the traffic does not match a Decryption policy. If you want to log traffic that you don’t decrypt, create a policy-based decryption exclusion and for policies that govern TLSv1.2 and earlier traffic, apply a No Decryption profile to the traffic.
PAN-OS supports Decryption logs for the following types of traffic:
  • Forward Proxy—Several fields only display information for Forward Proxy traffic, including Root CA (for trusted certificates only) and Server Name Identification (SNI).
  • Inbound Inspection.
  • No Decrypt (traffic excluded from decryption by Decryption policy).
    Because the session remains encrypted, the firewall displays 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-firewall only).
    GlobalProtect does not support TLSv1.3.
  • Decryption Mirror
Not all types of traffic support every parameter. Unsupported Parameters by Proxy Type and TLS Version provides a complete list of unsupported parameters for each type of decryption traffic.
The data for Forward Proxy traffic is based on whether the TLS handshake is successful or unsuccessful. For unsuccessful TLS handshakes, the firewall sends error data for the leg of the transaction that caused the error, either client-to-firewall or firewall-to-server. For successful TLS handshakes, the data is from the leg that successfully completes first, which is usually client-to-firewall.
The firewall does not generate Decryption log entries for web traffic blocked during SSL/TLS handshake inspection. These sessions do not appear in Decryption logs because the firewall 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.
Decryption logs are not supported for SSH Proxy traffic. In addition, certificate information is not available for session resumption logs.
By default, the firewall logs all unsuccessful TLS handshake traffic. You can also log successful TLS handshake traffic if you choose to do so. You can view up to 62 columns of log information such as application, SNI, Decryption Policy Name, error index, TLS version, key exchange version, encryption algorithm, certificate key types, and many other characteristics:
Click the magnifying glass icon ( ) to see the Detailed Log View of a session.
The Decryption log learns each session’s App-ID from the Traffic log, so Traffic logs must be enabled to see the App-ID in the Decryption log. If Traffic logs are disabled, the App-ID shows as
. For example, a lot of GlobalProtect traffic is intrazone traffic (Untrust zone to Untrust zone), but the default intra-zone policy does not enable Traffic logs. To see the App-ID for GlobalProtect intrazone traffic, you need to enable the Traffic log for intrazone traffic.
Another reason that the App-ID may display as
is that for long sessions, the firewall may generate the Decryption log before the Traffic log is complete (the Traffic log is usually generated at session end). In those cases, the App-ID is not available for the Decryption log. In addition, when the TLS handshake fails and generates an error log, the App-ID is not available because the failure terminates the session before the firewall can determine the App-ID. In these cases, the application may display as
or as
To troubleshoot issues, use the Decryption ACC widgets (
SSL Activity
) to identify traffic that causes decryption issues and then use the Decryption log and Custom Report Templates for Decryption to drill down into details.
When you forward Decryption logs for storage, ensure that you properly secure log transport and storage because Decryption logs contain sensitive information.
When the Decryption logs are enabled, the firewall sends HTTP/2 logs as Tunnel Inspection logs (when Decryption logs are disabled, HTTP/2 logs are sent as Traffic logs), so you need to check the Tunnel Inspection logs instead of the Traffic logs for HTTP/2 events. In addition, you must enable Tunnel Content Inspection to obtain the App-ID for HTTP/2 traffic.

Recommended For You