session_end_reason eq decrypt-error

Showing results for 
Show  only  | Search instead for 
Did you mean: 

session_end_reason eq decrypt-error

L2 Linker

I have a high number of sessions, for various webservers and clients, being closed due to decrypt-error. I've attempted to follow the tips from this document, but I'm still not clear on root cause:


Need help identifying why sessions are ending with message "decrypt-error"


Here are a few of the messages I'm seeing the debug logs:


2017-05-30 13:43:19.466 -0400 Error: pan_ssl3_client_process_handshake(pan_ssl_client.c:871): pan_ssl3_client_get_server_hello() failed
2017-05-30 13:43:19.466 -0400 Error: pan_ssl_proxy_handle_rt_hs(pan_ssl_proxy.c:236): pan_ssl3_process_handshake_message() failed -6
2017-05-30 13:43:19.466 -0400 Error: pan_ssl_proxy_parse_data(pan_ssl_proxy.c:550): pan_ssl_parse_record() failed
2017-05-30 13:43:19.467 -0400 Warning: pan_aho_fpga_lookup(pan_aho.c:2438): too many matches in buffer
2017-05-30 13:43:19.467 -0400 Warning: pan_aho_fpga_lookup(pan_aho.c:2438): too many matches in buffer
2017-05-30 13:43:19.462 -0400 Warning: pan_ssl3_server_get_client_hello(pan_ssl_server.c:1127): extra message at the end 2


L7 Applicator
What is "a high number" meaning? On which hardware do you have these problems? And because of the link you provided is it correct that you run 7.1.x?
Do you have an example of a decrypt-error-website and may be also analyzed this server for example on or or manually with openssl/sslyze?
But if you say a high number I assume at least some websites work, right? So it isn't a general decryption issue on your firewall.

Hi - by high number I mean it is happening frequently, but not all the time. So, it's not a general decryption issue but I'm having a hard time isolating it to any specific client or webserver behind the PA.  


I observed traffic logs for 1 client connecting to the same web server behind the PA 5020 and not all sessions end with the decrypt-error. Some end normally. 


Hardware is a 5020 running 7.1.10


I was thinking that if I have more info on the errors in the debug log, that'll help me narrow my search. 


Hello Amy,


Assuming this is for SSL forward proxy and not for inbound inspection.

Please collect these informations.

> show session all filter ssl-decrypt yes count yes
> show session all filter state discard



If you know any specific machine (source IP from the logs) please collect below mentioned information for get the actual reason for failure.

1. Enable packet-diag (ctd, ssl, proxy).
2. Enable packet capture on firewall (recv, firewall, drop) with a specific filter ( i.e source IP and destination set to
3. take global counter o/p 5 times with a 5 seconds interval.
> show counter global filter packet-filter yes delta yes

You may also check these 2 options.

a. Double check the min TLS version on the firewall
b. Disable Extended Master Secret on client



Hi Hulk - I should've specified this is for inbounc encryption.


What's the best way to check for the min tls version supported? 



The min TLS version is the one you configured in the decryption profile that you applied to the decryption rule. If you did not specify a profile the min version is sslv3

L1 Bithead

Did you ever get this fixed?

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!