Firewall rule without decryption but a TLS Handshake failure is logged in SSL/TLS inspection log

Rule ID1 is the rule 1 in TLS Decryption. 

Check if this rule is still applied to this traffic. The date is last week. Because Decryption is always logged, if it is applied. 

#1 is the default do not decrypt rule.

in FW Log I can see the rule 19 is applied and allowed.

and yes, it was a test last week, found only time for it today.

Yeah we are logging errors. TLS Rules does not mean, it is decrypting. Because the firewall and DPI engine still see "errors" in the application. This means, the app is failing for whatever reason (see above) to setup the TLS. This is at this point a "plain text communication". Therefore we can log it. 

You can check for this error: https://www.geeksforgeeks.org/how-to-fix-the-ssl-tls-handshake-failed-error/#:~:text=If%20the%20system%20date%20and,and%20have%20an%20expiration%20date.

I understand. So as the communication failed while handling out encryption, the firewall could see the unencrypted "to-be-encrypted" traffic and log's it because it "can do it".

It's OK for me. We were just struggling around and the colleagues argued, the firewall is intercepting the communication. in the end the tcpdump showed the incompatibility in ciphers I described initially.

thanks LuCar Toni !

I understand. So as the communication failed while handling out encryption, the firewall could see the unencrypted "to-be-encrypted" traffic and log's it because it "can do it".

It's OK for me. We were just struggling around and the colleagues argued, the firewall is intercepting the communication. in the end the tcpdump showed the incompatibility in ciphers I described initially.

thanks LuCar Toni !