The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The following topics provide an overview of creating, configuring, managing, and troubleshooting TLS/SSL rules:
 Note |
Because TLS and SSL are often used interchangeably, we use the expression TLS/SSL to indicate that either protocol is being discussed. The SSL protocol has been deprecated by the IETF in favor of the more secure TLS protocol, so you can usually interpret TLS/SSL as referring to TLS only. The exception is SSL policies. Because the FMC configuration option is , we use the term SSL policies although these policies are used to define rules for TLS and SSL traffic. For more information about SSL and TLS protocols, see a resource such as SSL vs. TLS - What's the Difference?. |
TLS/SSL rules provide a granular method of handling encrypted traffic across multiple managed devices, whether blocking the traffic without further inspection, not decrypting the traffic and inspecting it with access control, or decrypting the traffic for access control analysis.
Keep the following points in mind when setting up your TLS/SSL rules. Properly configuring TLS/SSL rules is a complex task, but one that is essential to building an effective deployment that handles encrypted traffic. Many factors influence how you configure rules, including certain application behavior that you cannot control.
In addition, rules can preempt each other, require additional licenses, or contain invalid configurations. Thoughtfully configured rules can also reduce the resources required to process network traffic. Creating overly complex rules and ordering rules the wrong way can adversely affect performance.
For detailed information, see Best Practices for Access Control Rules.
Set up Decrypt - Resign or Decrypt - Known Key rules only if your managed device handles encrypted traffic. Decryption rules require processing overhead that can impact performance.
If you create a Decrypt - Resign rule, and later add a security zone with passive interfaces to a zone condition, the system displays a warning icon next to the rule. Because you cannot decrypt traffic by re-signing a certificate in a passive deployment, the rule has no effect until you remove the passive interfaces from the rule or change the rule action.
Do not use accented characters (for example, Comunicación) in TLS/SSL rule rule names; doing so prevents the policy from being deployed to managed devices.
The Firepower System does not currently support TLS version 1.3 encryption or decryption. When users visit a web site that negotiates TLS 1.3 encryption, users might see errors similar to the following in their web browser:
ERR_SSL_PROTOCOL_ERROR
SEC_ERROR_BAD_SIGNATURE
ERR_SSL_VERSION_INTERFERENCE
For more information about how to control this behavior, contact Cisco TAC.
You should not decrypt traffic if doing so is forbidden by:
Law; for example, some jurisdictions forbid decrypting financial information
Company policy; for example, your company might forbid decrypting privileged communications
Privacy regulations
Traffic that uses certificate pinning (also referred to as TLS/SSL pinning) must remain encrypted to prevent breaking the connection
If you elect to bypass decryption for certain types of traffic, no processing is done on the traffic. The encrypted traffic is first evaluated by SSL policy and then proceeds to the access control policy, where a final allow or block decision is made. Encrypted traffic can be allowed or blocked on any TLS/SSL rule condition, including, but not limited to:
Certificate status (for example, expired or invalid certificate)
Protocol (for example, the nonsecure SSL protocol)
Network (security zone, IP address, VLAN tag, and so on)
Exact URL or URL category
Port
User group
You can associate one internal Certificate Authority (CA) 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 TLS/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.
We recommend the following:
Use the Decrypt - Resign rule action for decrypting outgoing traffic, as opposed to incoming traffic for which we recommend the Decrypt - Known Key rule action.
For more information about Decrypt - Known Key, see TLS/SSL Decrypt - Known Key Guidelines.
Always check the Replace Key Only check box when you set up a Decrypt - Resign rule action.
When a user browses to a web site that uses a self-signed certificate, the user sees a security warning in the web browser and is aware that they are communicating with an unsecure site.
When a user browses to a web site that uses a trusted certificate, the user does not see a security warning.
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 a TLS/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.
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 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.
Also note the following:
By nature, anonymous cipher suites are not used for authentication and do not use key exchanges. There are limited uses for anonymous cipher suites; for more information, see RFC 5246, appendix F.1.1.1. (Replaced for TLS 1.3 by RFC 8446 appendix C.5.)
You cannot use the Decrypt - Resign or Decrypt - Known Key action in the rule because anonymous cipher suites are not used for authentication.
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 (
) 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
(
) next to the rule. If you later add a zone condition to the TLS/SSL rule that contains passive or inline (tap mode) interfaces, the system displays a Warning (). If you deploy an SSL policy that contains a Decrypt - Resign rule to a device with passive or inline (tap mode) interfaces, any TLS/SSL sessions that match the rule fail.
To use a Decrypt - Resign rule action, you should create a Certificate Signing Request (CSR) and have it signed by a trusted certificate authority. (You can use the FMC to create a CSR: .)
To be used in a Decrypt - Resign rule, your certificate authority (CA) must have at least one of the following extensions:
CA: TRUE
For more information, see the discussion of Basic Constraints in RFC3280, section 4.2.1.10.
KeyUsage=CertSign
For more information see RFC 5280, section 4.2.1.3.
To verify your CSR or CA has at least one of the preceding extensions, you can use the openssl command as discussed in a reference such as the openssl documentation.
This is necessary because for Decrypt - Resign inspection to work, the certificate that used in the TLS/SSL policy generates certificates on-the-fly and signs them so as to act as man-in-the middle and proxy all TLS/SSL connections.
The following error is displayed if you attempt to save a TLS/SSL rule with a cipher suite that does not match the certificate. To resolve the issue, see Verify TLS/SSL Cipher Suites.
Traffic cannot match this rule; none of your selected cipher suites contain a
signature algorithm that the resigning CA's signature algorithmIf the client does not trust the Certificate Authority (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 the device.
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 TLS/SSL connection using the CONNECT HTTP method. The Handshake Errors undecryptable action determines how the system handles this traffic.
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.
Note |
Use the Cipher Suite and Version rule conditions only in rules with either the Block or Block with reset rule actions. The use of these conditions in rules with other rule actions can interfere with the system's ClientHello processing, resulting in unpredictable performance. |
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.
Also note the following:
) next to the rule. If you later add a zone condition to the TLS/SSL rule that contains passive or inline (tap mode) interfaces, the system displays a Warning ().
By nature, anonymous cipher suites are not used for authentication and do not use key exchanges. There are limited uses for anonymous cipher suites; for more information, see RFC 5246, appendix F.1.1.1. (Replaced for TLS 1.3 by RFC 8446 appendix C.5.)
You cannot use the Decrypt - Resign or Decrypt - Known Key action in the rule because anonymous cipher suites are not used for authentication.
You cannot match on Distinguished Name or Certificate conditions when creating a TLS/SSL rule with a 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 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
() 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 Warning () 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 a TLS/SSL rule with the Do not decrypt action to match the server certificate common name or distinguished name.
Note |
Use the Cipher Suite and Version rule conditions only in rules with either the Block or Block with reset rule actions. The use of these conditions in rules with other rule actions can interfere with the system's ClientHello processing, resulting in unpredictable performance. |
If decrypted traffic matches an access control rule with an action of Interactive Block or Interactive Block with reset, the system blocks the matching connection without interaction and the system does not display a response page.
Provided you enabled logging in your rule, two connection events are displayed (in ): One event for the interactive block and another event to indicate whether or not the user chose to continue to the site or not.
Some applications use a technique referred to as TLS/SSL pinning or certificate pinning, which embeds the fingerprint of the original server certificate in the application itself. As a result, if you configured a TLS/SSL rule with a Decrypt - Resign action, when the application receives a resigned certificate from a managed device, validation fails and the connection is aborted.
Because TLS/SSL pinning is used to avoid man-in-the-middle attacks, there is no way to prevent or work around it. You have the following options:
Create a Do Not Decrypt for those applications rule ordered before Decrypt - Resign rules.
Instruct users to access the applications using a web browser.
For more information about rule ordering, see SSL Rule Order.
Some applications use the TLS heartbeat extension to the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols defined by RFC6520. TLS heartbeat provides a way to confirm the connection is still alive—either the client or server sends a specified number of bytes of data and requests the other party echo the response. If this is successful, encrypted data is sent.
You can configure a Max Heartbeat Length in a Network Analysis Policy (NAP) to determine how to handle TLS heartbeats. For more information, see The SSL Preprocessor.
By nature, anonymous cipher suites are not used for authentication and do not use key exchanges. There are limited uses for anonymous cipher suites; for more information, see RFC 5246, appendix F.1.1.1. (Replaced for TLS 1.3 by RFC 8446 appendix C.5.)
You cannot use the Decrypt - Resign or Decrypt - Known Key action in the rule because anonymous cipher suites are not used for authentication.
You can add an anonymous cipher suite to the Cipher Suite condition in a TLS/SSL rule, but the system automatically strips anonymous cipher suites during ClientHello processing. For the system to use the rule, you must also configure your TLS/SSL rules in an order that prevents ClientHello processing. For more information, see SSL Rule Order.
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 TLS/SSL session. If the traffic is allowed, the trimmed packet is encrypted as part of the TLS/SSL session.
If you add a group or user to a rule, then change your realm settings to exclude that group or user, the rule has no effect. (The same applies to disabling the realm.) For more information about realms, see Create a Realm.
If your SSL policy has a Decrypt - Resign action but web sites are not being decrypted, check Category page on rules associated with that policy.
In some cases, a web site redirects to another site for authentication or other purposes and the redirected site might have a different URL categorization than the site you're trying to decrypt. For example, gmail.com (Web based email category) redirects to accounts.gmail.com (Internet Portals category) for authentication. Be sure to include all relevant categories in the SSL rule.
Note |
In order to fully process traffic based on URL category, you must also configure URL filtering. See the URL Filtering chapter. |
If you create a Decrypt - Resign rule and users browse to a web site whose category and reputation are not in the local database, data might not be decrypted. Some web sites are not categorized in the local database and, if not, data from those web sites is not decrypted by default.
You can control this behavior with the setting System > Integration > Cisco CSI , and check Query Cisco CSI for Unknown URLs.
For more information about this option, see Cisco Clouds.
Any except NGIPSv.
Any
Admin
Access Admin
Network Admin
You must create reusable public key infrastructure (PKI) objects to control encrypted traffic based on encrypted session characteristics and decrypt encrypted traffic. You can add this information on the fly when uploading trusted certificate authority (CA) certificates to the SSL policy and creating SSL rule conditions, creating the associated object in the process. However, configuring these objects ahead of time reduces the chance of improper object creation.
The system can decrypt incoming encrypted traffic if you configure an internal certificate object by uploading the server certificate and private key used to encrypt the session. If you reference that object in an SSL rule with an action of Decrypt - Known Key and traffic matches that rule, the system uses the uploaded private key to decrypt the session.
The system can also decrypt outgoing traffic if you configure an internal CA object by uploading a CA certificate and private key. If you reference that object in a TLS/SSL rule with an action of Decrypt - Resign and traffic matches that rule, the system re-signs the server certificate passed to the client browser, then acts as a man-in-the-middle to decrypt the session.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.
The system can control encrypted traffic based on the cipher suite or server certificate used to negotiate the session. You can configure one of several different reusable objects and reference the object in a TLS/SSL rule condition to match traffic. The following table describes the different types of reusable objects you can configure:
|
If you configure... |
You can control encrypted traffic based on whether... |
|---|---|
|
A cipher suite list containing one or more cipher suites |
The cipher suite used to negotiate the encrypted session matches a cipher suite in the cipher suite list |
|
A trusted CA object by uploading a CA certificate your organization trusts |
The trusted CA trusts the server certificate used to encrypt the session, whether:
|
|
An external certificate object by uploading a server certificate |
The server certificate used to encrypt the session matches the uploaded server certificate |
|
A distinguished name object containing a certificate subject or issuer distinguished name |
The subject or issuer common name, country, organization, or organizational unit on the certificate used to encrypt the session matches the configured distinguished name |
|
Step 1 |
Log in to the Firepower Management Center. |
|
Step 2 |
Click . |
|
Step 3 |
Click Edit ( If View ( |
|
Step 4 |
You have the following choices:
|
|
Step 5 |
Enter a Name for the rule. Do not use accented characters (for example, Comunicación) in TLS/SSL rule rule names; doing so prevents the policy from being deployed to managed devices. |
|
Step 6 |
Specify whether the rule is Enabled. |
|
Step 7 |
Specify the rule position; see TLS/SSL Rule Order Evaluation. |
|
Step 8 |
Click a rule Action; see Configuring TLS/SSL Rule Actions. |
|
Step 9 |
Configure the rule’s conditions; see TLS/SSL Rule Condition Types. |
|
Step 10 |
Click Save. If the following error displays, see Verify TLS/SSL Cipher Suites: Traffic cannot match this rule; none of your selected cipher suites contain a signature algorithm that the resigning CA's signature algorithm . |
Deploy configuration changes; see Deploy Configuration Changes.
|
Step 1 |
In the SSL rule editor, from the Insert drop-down list, select Into Category, then select the category you want to use. |
||
|
Step 2 |
Click Save.
|
Deploy configuration changes; see Deploy Configuration Changes.
|
Step 1 |
In the SSL rule editor, from the Insert drop-down list, select above rule or below rule, then type the appropriate rule number. |
||
|
Step 2 |
Click Save.
|
Deploy configuration changes; see Deploy Configuration Changes.
You can search the list of TLS/SSL rules for matching values using an alphanumeric string, including spaces and printable, special characters. The search inspects the rule name and any rule condition you have added to the rule. For rule conditions, the search matches any name or value you can add for each condition type (zone, network, application, and so on). This includes individual object names or values, group object names, individual object names or values within a group, and literal values.
You can use complete or partial search strings. The column for
matching values is highlighted for each matching rule. For example, if you
search on all or part of the string
100Bao, at a minimum, the Applications column is
highlighted for each rule where you have added the 100Bao application. If you
also have a rule named
100Bao, both the Name and Applications columns are
highlighted.
You can navigate to each previous or next matching rule. A status message displays the current match and the total number of matches.
Matches may occur on any page of a multi-page rule list. When the first match is not on the first page, the page where the first match occurs is displayed. Selecting the next match when you are at the last match takes you to the first match, and selecting the previous match when you are at the first match takes you to the last match.
|
Step 1 |
In the SSL policy editor, click the Search Rules prompt, type a search string, then press Enter.
|
||
|
Step 2 |
Find the rules you are interested in:
|
When you create a TLS/SSL rule, it is enabled by default. If you disable a rule, the system does not use it to evaluate network traffic and stops generating warnings and errors for that rule. When viewing the list of rules in an SSL policy, disabled rules are grayed out, although you can still modify them. Note that you can also enable or disable a TLS/SSL rule using the rule editor.
|
Step 1 |
In the SSL policy editor, right-click a rule and choose a rule state. |
|
Step 2 |
Click Save. |
Deploy configuration changes; see Deploy Configuration Changes.
|
Step 1 |
In the SSL policy editor, select the rules by clicking in a blank area for each rule. |
||
|
Step 2 |
Right-click the rule and select Cut. |
||
|
Step 3 |
Right-click a blank area for a rule next to where you want to paste the cut rules and select Paste above or Paste below.
|
||
|
Step 4 |
Click Save. |
Deploy configuration changes; see Deploy Configuration Changes.
You can create custom categories between the Standard Rules and Root Rules categories to further organize your rules without having to create additional policies. You can rename and delete categories that you add. You cannot move these categories, but you can move rules into, within, and out of them.
|
Step 1 |
In the policy editor, click Add Category.
|
||
|
Step 2 |
Type a Name. |
||
|
Step 3 |
You have the following choices:
|
||
|
Step 4 |
Click OK.
|
||
|
Step 5 |
Click Save. |
An SSL rule’s conditions identify the type of encrypted traffic the rule handles. Conditions can be simple or complex, and you can specify more than one condition type per rule. Only if traffic meets all the conditions in a rule does the rule apply to the traffic.
If you do not configure a particular condition for a rule, the system does not match traffic based on that criterion. For example, a rule with a certificate condition but no version condition evaluates traffic based on the server certificate used to negotiate the session, regardless of the session SSL or TLS version.
Every TLS/SSL rule has an associated action that determines the following for matching encrypted traffic:
Handling: Most importantly, the rule action governs whether the system will monitor, trust, block, or decrypt encrypted traffic that matches the rule’s conditions
Logging: The rule action determines when and how you can log details about matching encrypted traffic.
Your TLS/SSL inspection configuration handles, inspects, and logs decrypted traffic:
The SSL policy’s undecryptable actions handle traffic that the system cannot decrypt.
The policy’s default action handles traffic that does not meet the condition of any non-Monitor TLS/SSL rule.
You can log a connection event when the system blocks or trusts an encrypted session. You can also force the system to log connections that it decrypts for further evaluation by access control rules, regardless of how the system later handles or inspects the traffic. Connection logs for encrypted sessions contain details about the encryption, such as the certificate used to encrypt that session. You can log only end-of-connection events, however:
For blocked connections (Block, Block with reset), the system immediately ends the sessions and generates an event
For trusted connections (Do not decrypt), the system generates an event when the session ends
When you add or edit an SSL rule, use the tabs on the left side of the lower portion of the rule editor to add and edit rule conditions.
|
This Condition... |
Matches Encrypted Traffic... |
Details |
|---|---|---|
|
Zones |
Entering or leaving a device via an interface in a specific security zone |
A security zone is a logical grouping of one or more interfaces according to your deployment and security policies. Interfaces in a zone may be located across multiple devices. |
|
Networks |
By its source or destination IP address, country, or continent |
You can explicitly specify IP addresses. The geolocation feature also allows you to control traffic based on its source or destination country or continent. |
|
VLAN Tags |
Tagged by VLAN |
The system uses the innermost VLAN tag to identify a packet by VLAN. |
|
Ports |
By its source or destination port |
You can control encrypted traffic based on the TCP port. |
|
Users |
By the user involved in the session |
You can control encrypted traffic based on the LDAP user logged into a host involved in an encrypted, monitored session. You can control traffic based on individual users or groups retrieved from a Microsoft Active Directory server. |
|
Applications |
By the application detected in a session |
You can control access to individual applications in encrypted sessions, or filter access according to basic characteristics: type, risk, business relevance, and categories. |
|
Categories |
By the URL requested in the session, based on the certificate subject distinguished name |
You can limit the websites that users on your network can access based on the URL’s general classification and risk level. |
|
Distinguished Names |
The URL the user enters in the browser matches the Common Name (CN), or the URL is contained in the certificate's Subject Alternative Name (SAN) |
You can control encrypted traffic based on the CA that issued a server certificate, or the server certificate holder. |
|
Certificates |
By the server certificate used to negotiate the encrypted session |
You can control encrypted traffic based on the server certificate passed to the user’s browser in order to negotiate the encrypted session. |
|
Certificate Status |
By properties of the server certificate used to negotiate the encrypted session |
You can control encrypted traffic based on a server certificate’s status. |
|
Cipher Suites |
By the cipher suite used to negotiate the encrypted session |
You can control encrypted traffic based on the cipher suite selected by the server to negotiate the encrypted session. |
|
Versions |
By the version of SSL or TLS used to encrypt the session |
You can control encrypted traffic based on the version of SSL or TLS used to encrypt the session. |
The following sections discuss the actions available with TLS/SSL rules.
The Monitor action is not designed to permit or deny traffic. Rather, its primary purpose is to force connection logging, regardless of how matching traffic is eventually handled. Traffic is then matched against additional rules, if present, to determine whether to trust, block, or decrypt it. The first non-Monitor rule matched determines traffic flow and any further inspection. If there are no additional matching rules, the system uses the default action.
Because the primary purpose of Monitor rules is to track network traffic, the system automatically logs end-of connection events for monitored traffic to the Firepower Management Center database, regardless of the logging configuration of the rule or default action that later handles the connection.
The Do Not Decrypt action passes encrypted traffic for evaluation by the access control policy’s rules and default action. Because some access control rule conditions require unencrypted traffic, this traffic may match fewer rules. The system cannot perform deep inspection on encrypted traffic, such as intrusion or file inspection.
Typical reasons for a Do Not Decrypt rule action include:
When decrypting TLS/SSL traffic is prohibited by law.
Sites you know you can trust.
Sites you can disrupt by inspecting traffic (such as Windows Update).
To view the values of TLS/SSL fields using connection events. (You do not need to decrypt traffic to view connection event fields.) For more information, see Requirements for Populating Connection Event Fields.
For more information, see Default Handling Options for Undecryptable Traffic
The Firepower System provides the following TLS/SSL rule actions for traffic you do not want to pass through the system:
Block to terminate the connection, resulting in an error in the client browser.
The error message does not indicate the site was blocked due to policy. Instead, errors might indicate that there are no common encryption algorithms. It is not obvious from this message that you blocked the connection on purpose.
Block with reset to terminate and reset the connection, resulting in an error in the client browser.
The error indicates the connection was reset but does not indicate why.
 Tip |
You cannot use the Block or Block with reset action in a passive or inline (tap mode) deployment because the device does not directly inspect the traffic. If you create
a rule with the Block or Block with reset action that contains passive or inline (tap mode) interfaces within a security zone condition, the policy editor displays
a warning ( |
The Decrypt - Known Key and Decrypt - Resign actions decrypt encrypted traffic. The system inspects decrypted traffic with access control. Access control rules handle decrypted and unencrypted traffic identically — you can inspect it for discovery data as well as detect and block intrusions, prohibited files, and malware. The system reencrypts allowed traffic before passing it to its destination.
We recommend you use a certificate from a trusted Certificate Authority (CA) to decrypt traffic. This prevents Invalid Issuer from being displayed in the SSL Certificate Status column in connection events.
For more information about adding trusted objects, see Trusted Certificate Authority Objects.
See:
|
Step 1 |
In the SSL policy editor, you have the following options:
|
|
Step 2 |
Select a rule action from the Action drop-down list.
|
|
Step 3 |
Click Add. |
Configure rule conditions, as described in Network-Based TLS/SSL Rule Conditions, User-Based TLS/SSL Rule Conditions, Reputation-Based TLS/SSL Rule Conditions, and Server Certificate-Based TLS/SSL Rule Conditions.
Deploy configuration changes; see Deploy Configuration Changes.
|
Step 1 |
In the SSL rule editor, select Decrypt - Resign from the Action list. |
|
Step 2 |
Select an internal CA certificate object from the list. |
|
Step 3 |
Check . Always check the Replace Key Only check box when you set up a Decrypt - Resign rule action. When a user browses to a web site that uses a self-signed certificate, the user sees a security warning in the web browser and is aware that they are communicating with an unsecure site. When a user browses to a web site that uses a trusted certificate, the user does not see a security warning. |
|
Step 4 |
Click Add. |
|
Step 5 |
Optional. To use a Trusted CA certificate in your SSL policy so you can avoid Invalid Issuer in the SSL Certificate Status column in connection events, add the certificate to the policy:
|
Deploy configuration changes; see Deploy Configuration Changes.
|
Step 1 |
In the SSL rule editor, select Decrypt - Known Key from the Action drop-down list. |
|
Step 2 |
Click the Click to select decryption certs field. |
|
Step 3 |
Select one or more internal certificate objects in the Available Certificates list, then click Add to Rule. |
|
Step 4 |
Click OK. |
|
Step 5 |
Click Add. |
|
Step 6 |
Optional. To use a Trusted CA certificate in your SSL policy so you can avoid Invalid Issuer in the SSL Certificate Status column in connection events, add the certificate to the policy:
|
Deploy configuration changes; see Deploy Configuration Changes.
The Rules page of the SSL policy editor allows you to add, edit, search, move, enable, disable, delete, and otherwise manage TLS/SSL rules in your policy.
)
)
)
) next to the rule.
Feedback