When you configure the
Decrypt - Known Key action, you can associate one or
more server certificates and paired private keys with the action. If traffic
matches the rule, and the certificate used to encrypt the traffic matches the
certificate associated with the action, the system uses the appropriate private
key to obtain the session encryption and decryption keys. Because you must have
access to the private key, this action is best suited to decrypt traffic
incoming to servers your organization controls.
Similarly, you can associate one Certificate Authority
certificate and private key with the
Decrypt - Resign action. If traffic matches this
rule, the system re-signs the server certificate with the CA certificate, then
acts as a man-in-the-middle. It creates two SSL sessions, one between client
and managed device, one between managed device and server. Each session
contains different cryptographic session details, and allows the system to
decrypt and reencrypt traffic. This action is more suited for outgoing traffic,
as you replace the certificate’s private key with one you control to obtain the
Re-signing a server certificate involves either replacing the
certificate’s public key with a CA certificate public key, or replacing the
entire certificate. Normally, if you replace an entire server certificate, the
client browser warns the certificate is not signed by a trusted authority when
establishing the SSL connection. However, if your client’s browser trusts the
CA in the policy, the browser does not warn that the certificate is not
trusted. If the original server certificate is self-signed, the system replaces
the entire certificate, and trusts the re-signing CA, but the user’s browser
does not warn that the certificate is self-signed. In this case, replacing only
the server certificate public key causes the client browser does warn that the
certficate is self-signed.
If you configure a rule with the Decrypt - Resign action, the rule matches traffic based on the referenced internal CA certificate’s signature algorithm type, in addition to any configured rule conditions. Because you associate one CA certificate with a Decrypt - Resign action, you cannot create an SSL rule that decrypts multiple types of outgoing traffic encrypted with different signature algorithms. In addition, any external certificate objects and cipher suites you add to the rule must match the associated CA certificate encryption algorithm type. You can optionally replace the self-signed certificate key only and not the entire certificate, in which case users see a self-signed certificate key notice in the browser.
For example, outgoing traffic encrypted with an elliptic curve
(EC) algorithm matches a
Decrypt - Resign rule only if the action references
an EC-based CA certificate; you must add EC-based external certificates and
cipher suites to the rule if you want to create certificate and cipher suite
rule conditions. Similarly, a
Decrypt - Resign rule that references an RSA-based
CA certificate matches only outgoing traffic encrypted with an RSA algorithm;
outgoing traffic encrypted with an EC algorithm does not match the rule, even
if all other configured rule conditions match.
Note the following:
You cannot use the
Decrypt - Known Key action in a passive deployment
if the cipher suite used to establish the SSL connection applies either the
Diffie-Hellman ephemeral (DHE) or the elliptic curve Diffie-Hellman ephemeral
(ECDHE) key exchange algorithm. If your SSL policy targets a device with
passive or inline (tap mode) interfaces, and contains a
Decrypt - Known Key rule with a cipher suite
condition containing either a DHE or an ECDHE cipher suite, the system displays
an information icon ()
next to the rule. If you later add a zone condition to the SSL rule that
contains passive or inline (tap mode) interfaces, the system displays a warning
You cannot use the Decrypt - Resign action in a passive or inline (tap mode) deployment because the device does not directly inspect traffic. If you create a rule with the Decrypt - Resign action that contains passive or inline (tap mode) interfaces within a security zone, the policy editor displays a warning icon () next to the rule. If your SSL policy targets a device with passive or inline (tap mode) interfaces, and contains a Decrypt - Resign rule, the system displays an information icon () next to the rule. If you later add a zone condition to the SSL rule that contains passive or inline (tap mode) interfaces, the system displays a warning icon (). If you deploy an SSL policy that contains a Decrypt - Resign rule to a device with passive or inline (tap mode) interfaces, any SSL sessions that match the rule fail.
If the client does not trust the CA used to re-sign the server
certificate, it warns the user that the certificate should not be trusted. To
prevent this, import the CA certificate into the client trusted CA store.
Alternatively, if your organization has a private PKI, you can issue an
intermediate CA certificate signed by the root CA which is automatically
trusted by all clients in the organization, then upload that CA certificate to
You can add an anonymous cipher suite to the Cipher Suite condition in an SSL rule, but keep in mind:
The system automatically strips anonymous cipher suites during ClientHello processing. For the system to use the rule, you must also configure your SSL rules in an order that prevents ClientHello processing. For more information, see SSL Rule Order.
You cannot use the Decrypt - Resign or Decrypt - Known Key action in the rule, because the system cannot decrypt traffic encrypted with an anonymous cipher suite.
The system cannot decrypt traffic if an HTTP proxy is positioned
between a client and your managed device, and the client and server establish a
tunneled SSL connection using the CONNECT HTTP method. The
Handshake Errors undecryptable action determines how
the system handles this traffic.
The system cannot decrypt traffic in the captive portal
authentication connection between a captive portal user's web browser and the
captive portal daemon on the managed device.
You cannot match on
Distinguished Name or
Certificate conditions when creating an SSL rule
Decrypt - Known Key action. The assumption is that
if this rule matches traffic, the certificate, subject DN, and issuer DN
already match the certificate associated with the rule.
If you create an internal CA object and choose to generate a
certificate signing request (CSR), you cannot use this CA for a
Decrypt - Resign action until you upload the signed
certificate to the object.
If you configure a rule with the
Decrypt - Resign action, and mismatch signature
algorithm type for one or more external certificate objects or cipher suites,
the policy editor displays an information icon ()
next to the rule. If you mismatch signature algorithm type for all external
certificate objects, or all cipher suites, the policy displays a warning icon
next to the rule, and you cannot deploy the access control policy associated
with the SSL policy.
If the customer's browser uses certificate pinning to verify a server certificate, you cannot decrypt this traffic by re-signing the server certificate. To allow this traffic, configure an SSL rule with the Do not decrypt action to match the server certificate common name or distinguished name.
If decrypted traffic matches an access control rule with an action of Interactive Block or Interactive Block with reset, the system displays a response page.
If you enable the Normalize Excess Payload option in the inline normalization preprocessor, when the preprocessor normalizes decrypted traffic, it might drop a packet and replace it with a trimmed packet. This does not end the SSL session. If the traffic is allowed, the trimmed packet is encrypted as part of the SSL session.