Cisco Secure Firewall decryption policies determine how TLS\/SSL traffic is decrypted, bypassed, blocked, or evaluated before access-control and deeper inspection. Current Secure Firewall Management Center and Device Manager 7.7 documentation separates actions such as Decrypt – Re-sign for outbound client traffic, Decrypt – Known Key for inbound servers where the private key is available, Do Not Decrypt for exclusions, and certificate\/protocol handling rules. Decryption enables URL filtering, intrusion, malware, application identification, and identity controls that cannot see inside encrypted payloads.<\/p>\n
Within Cisco Network Engineering<\/a>, the right design is selective decryption. Decryption Policy: Why There Is No Single Right Answer<\/a> covers the broad trade-off.<\/p>\n Encrypted connections are evaluated by the decryption policy before higher-layer inspection can analyze plaintext.<\/p>\n Traffic that is not blocked proceeds to access control whether it was decrypted or bypassed.<\/p>\n This means a Do Not Decrypt rule is not an allow rule by itself; downstream access policy still decides whether the flow is permitted.<\/p>\n For client-to-internet TLS, Secure Firewall acts as a TLS intermediary, presents a re-signed server certificate to the client, decrypts the traffic, inspects it, and re-encrypts toward the real server.<\/p>\n Clients must trust the enterprise CA certificate used for re-signing.<\/p>\n Manage that CA like a high-value security credential and distribute trust through endpoint management rather than manual browser imports.<\/p>\n Where the firewall has the server’s private key\/certificate material for supported inbound TLS inspection, known-key decryption can inspect sessions without re-signing the server certificate for clients.<\/p>\n Key handling, certificate renewal, HSM\/secret processes, and TLS termination architecture become dependencies.<\/p>\n Use only for services where private-key exposure to the firewall is acceptable.<\/p>\n Privacy-sensitive categories, certificate-pinned applications, mutual-TLS services, financial\/health use cases, or technically incompatible traffic may need decryption exclusions.<\/p>\n Place specific exclusions before broad decrypt rules.<\/p>\n Every bypass is a visibility gap, so record owner, reason, scope, and review date rather than creating permanent \u201ctemporary\u201d exemptions.<\/p>\n Current Cisco best-practice examples recommend putting quick specific matches such as known IP exclusions early, then targeted decryption, and more processing-intensive certificate\/protocol rules later.<\/p>\n Rules are first-match.<\/p>\n Keep policy readable enough that an analyst can explain why one destination was decrypted while another was bypassed.<\/p>\n TLS failures can result from unsupported cipher\/protocol behavior, certificate issues, client authentication, pinning, or application-specific handshake logic.<\/p>\n Secure Firewall provides configurable handling for undecryptable sessions.<\/p>\n Choose whether to block or bypass based on risk and user impact instead of letting errors silently become full-visibility bypasses.<\/p>\n Secure Firewall 7.x supports TLS 1.3 decryption within documented capabilities and best practices, but client\/server behavior and encrypted extensions can affect policy matching and inspection.<\/p>\n Keep firewall\/VDB\/software releases current and validate important SaaS applications after upgrades.<\/p>\n Do not assume an old SSL policy designed around TLS 1.2 has identical behavior under current TLS 1.3 traffic.<\/p>\n Decryption policies can monitor or block certificate conditions, protocol versions, ciphers, and other TLS properties depending on platform\/version.<\/p>\n Use this to enforce minimum TLS posture where business compatibility permits.<\/p>\n Stage weak-protocol blocks with logging first to identify legacy applications before enforcement.<\/p>\n Current Secure Firewall documentation notes that identity-policy active authentication requires the SSL decryption policy to be enabled because the system must intercept traffic to perform authentication redirection.<\/p>\n These automatically created identity-related decryption rules are evaluated before manually created native rules.<\/p>\n Troubleshoot identity and decryption together when captive\/active authentication suddenly stops working.<\/p>\n Track decryption success\/failure, bypass reasons, certificate errors, TLS versions, performance\/CPU impact, user complaints, and application exclusions.<\/p>\nUnderstand where decryption sits in packet processing<\/h3>\n
Decrypt – Re-sign is the outbound inspection pattern<\/h3>\n
Decrypt – Known Key fits owned inbound services<\/h3>\n
Do Not Decrypt rules are necessary but dangerous when broad<\/h3>\n
Rule order matters<\/h3>\n
Undecryptable traffic needs an explicit default<\/h3>\n
TLS 1.3 requires current platform\/client planning<\/h3>\n
Certificate status and protocol rules can block weak sessions<\/h3>\n
Active authentication depends on decryption in some designs<\/h3>\n
Measure decryption health continuously<\/h3>\n