The No Decryption profile blocks risky sessions for traffic
that you choose not to decrypt by policy rule.
No Decryption profiles (
perform server verification checks for traffic that you choose not
to decrypt. You attach a No Decryption profile to a “No Decryption” Decryption policy that
defines the traffic to exclude from decryption. (Don’t use policy
to exclude traffic that you can’t decrypt because a site breaks
decryption for technical reasons such as a pinned certificate or
mutual authentication. Instead, add the hostname to the Decryption Exclusion List.) The following
figure shows the general best practice recommendations for the No
Decryption profile settings, but the settings you use also depend
on your company’s security compliance rules and local laws and regulations.
Block sessions with expired certificates
this box to block sessions with servers that have expired certificates and
prevent access to potentially insecure sites. If you don’t check
this box, users can connect with and transact with potentially malicious
sites and see warning messages when they attempt to connect, but
the connection is not prevented.
Block sessions with untrusted issuers
—Check this box
to block sessions with servers that have untrusted certificate issuers.
An untrusted issuer may indicate a man-in-the-middle attack, a replay attack,
or other attack.
Do not attach a No Decryption profile to Decryption policies
for TLSv1.3 traffic that you don’t decrypt. Unlike previous versions, TLSv1.3
encrypts certificate information, so the firewall has no visibility
into certificate data and therefore cannot block sessions with expired
certificates or untrusted issuers, so the profile has no effect.
(The firewall can perform certificate checks with TLSv1.2 and earlier
because those protocols do not encrypt certificate information and
you should apply a No Decryption profile to their traffic.) However,
you should create a Decryption policy for TLSv1.3 traffic that you
don’t decrypt because the firewall doesn’t log undecrypted
traffic unless a Decryption policy controls that traffic.
(Applies to TLSv1.2 and earlier) If you choose to allow
sessions with untrusted issuers (not recommended) and only
sessions with expired certificates
, there is a scenario
in which a session with a trusted, expired issuer may be blocked inadvertently.
When the firewall’s certificate store contains a valid, self-signed
Trusted CA and the server sends an expired CA in the certificate
chain, the firewall does not check its certificate store. Instead,
the firewall 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.
avoid this scenario, in addition to
Block sessions with
with untrusted issuers
. This forces the firewall to
check its certificate store, find the self-signed Trusted CA, and
allow the session.