> Source: [sk108202](https://support.checkpoint.com/results/sk/sk108202) # sk108202 - Best Practices - HTTPS Inspection | Property | Value | |----------|-------| | Solution ID | sk108202 | | Date Created | 2015-10-14 | | Last Modified | 2026-03-22 | | Technical Level | General | | Products | Security Gateway | | Versions | R82, R81.20, R81.10 (EOS), R81 (EOS) | | OS | Gaia | ## Solution This article outlines some recommendations and best practices for easy HTTPS Inspection deployment and usage to help avoid common configuration issues. **Table of Contents:** * Part 1 - Introduction 1. HTTPS Inspection - Inbound vs. Outbound 2. Gradual Deployment 3. Initial configuration * Part 2 - Best Practices 1. Configuring inbound certificates 2. Configuring outbound certificates 3. Creating the HTTPS Inspection Rule Base 4. Internet connection 5. Monitor TLS connections * Part 3 - Additional Information 1. Perfect Forward Secrecy Cipher Suites 2. Certificate-pinned Applications 3. Update Services 4. Traffic over QUIC or HTTP/3 5. Categorized HTTPS vs. HTTPS Inspection 6. HTTPS Inspection support for Post-Quantum Cryptography (PQC) * Part 4 - Performance * Part 5 - Debug 1. Notes 2. WSTLSD daemon (TLS handshake) 3. Firewall debug 4. HTTPS Inspection rulebase matching * Part 6 - Related documentation * Part 7 - Related solutions * Part 8 - Revision history Click Here to Show the Entire Article ### (Part 1) Introduction {#Introduction} > HTTPS Internet traffic uses the TLS (Transport Layer Security) or SSL (Secure Sockets Layer) protocol and is encrypted to give data privacy and integrity. > > However, HTTPS traffic has a possible security risk and can hide illegal user activity and malicious traffic. > > With HTTPS Inspection, the Security Gateway can inspect the traffic that is encrypted by HTTPS. > > The Security Gateway uses certificates and becomes an intermediary between the client computer and the secure web site. > > All data is kept private in HTTPS Inspection logs. > > Only administrators with HTTPS Inspection permissions can see all the fields in a log. > > HTTPS ratio of internet traffic is constantly growing. > > However, malicious attacks, dangerous web activity and data loss can hide away from the inspection of the Security Gateway under the TLS layer. > > Therefore, we recommend to enable HTTPS Inspection to improve security. > > By enabling HTTPS Inspection, the Security Gateway will inspect the encrypted parts of the HTTPS traffic. > > The HTTPS Inspection Rule Base is a set of rules used to define which HTTPS traffic will be inspected by the Security Gateway. > > The inspection will be performed by all the Software Blades that support HTTPS Inspection: > > * Application Control > * URL Filtering > * IPS > * Data Loss Prevention (DLP) > * Anti-Virus > * Anti-Bot > * Threat Emulation > * Content Awareness > > #### (Part 1 - 1) Introduction: HTTPS Inspection - Inbound vs. Outbound {#Introduction - HTTPS Inspection - Inbound vs. Outbound} > > Show / Hide this section > > * ***Inbound HTTPS Inspection*** protects internal servers (for example, data centers and web servers) from malicious attacks coming from the Internet. > > > > Inbound connections are HTTPS connections that start from an external client and connect to an internal server in the DMZ or the network. > > > > The Security Gateway compares the HTTPS request to the HTTPS Inspection Rule Base. > > > > If the request does not match a rule, the packet is not decrypted. > > > > If the request matches an inspection rule, the Security Gateway uses the certificate for the internal server to create a HTTPS connection with the external client. > > > > The Security Gateway creates a new HTTPS connection with the internal server. > > > > Since the Security Gateway has a secure connection with the external client, it can decrypt the HTTPS traffic. > > > > The decrypted traffic is inspected according to the policy. > > > > Flow on Security Gateway: > > 1. Intercept the request. > > 2. Use the server's original certificate and private key to initiate a TLS connection with the client. > > 3. Create and establishes a new TLS connection with the web server. > > 4. Using the two TLS connections: > > 1. Decrypt the encrypted data from the client. > > 2. Inspect the clear text content for all blades set in the policy. > > 3. Encrypt the data again to keep client privacy as the data travels to the destination server behind the Security Gateway. > > > > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk108202/Inspecting_Inbound_HTTPS_Packets.png) > > * ***Outbound HTTPS Inspection*** protects internal users and perimeter servers from malicious attacks coming from the Internet on connections originated from inside the organization. > > > > Outbound connections are HTTPS connections that start from an internal client and connect to the Internet. > > > > The Security Gateway compares the HTTPS request to the HTTPS Inspection Rule Base. > > > > If the request does not match a rule, the packet is not decrypted. > > > > If the request matches an inspection rule, the Security Gateway makes sure that the certificate from the server (in the Internet) is valid. > > > > The Security Gateway creates a new certificate, and presents it to the client, when the client creates an HTTPS connection to the gateway. > > > > There are two HTTPS connections, one to the internal client and one to the server. > > > > It can then decrypt and inspect the packets according to the Security Gateway and other Rule Bases. > > > > The packets are encrypted again and sent to the destination. > > > > Flow on Security Gateway: > > 1. Intercept the request. > > 2. Establish a secure connection with the requested server and validate its certificate using a separate probing connection. > > 3. Make an inspection or bypass decision based on the rule matched using information gathered from the original connection and server certificate. > > 4. When a decision to inspect is made, establish a secure connection with the requested server. > > 5. Create a new TLS certificate for the communication between the Security Gateway and the client, send the client the new certificate and continue the TLS negotiation with it. > > 6. Using the two TLS connections: > > 1. Decrypt the encrypted data received. > > 2. Inspect the clear text content for all blades set in the Policy. > > 3. Inspect the traffic coming from the web site into the organization. > > 4. Encrypt the data again to keep client privacy as the data travels to the destination web server resource. > > > > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk108202/Outbound202107291520171.png) > > > > Note: There are bypass mechanisms which were not elaborated in the flowchart to keep it simple. > > #### (Part 1 - 2) Introduction: Gradual Deployment {#Introduction - Gradual Deployment} > > Show / Hide this section > > When first enabling HTTPS Inspection, we recommend to use a ***gradual*** approach. Consider one of the following methods: > > > > 1. Starting from R82, the Learning Mode feature offers a way to partially deploy HTTPS Inspection and estimate its effect on connectivity and performance issues. With Learning mode, the Security Gateway inspects a small percentage of the traffic to identify connectivity issues and estimate the expected resource consumption for the configured HTTPS Inspection policy. In HTTPS Inspection Deployment View you can see the effect of the learning mode and the statuses of all Security Gateways. For more details, refer to [HTTPS Inspection Learning Mode recommendation](https://support.checkpoint.com/results/sk/sk182679). > > > > **Note** - We recommend to configure Learning Mode with a rule that inspects all networks to ensure that sufficient data is collected for generating accurate recommendations. > > 2. In all versions, you can perform a manual gradual deployment - Begin with a few Security Gateways and networks, and expand from there to cover all Security Gateways and networks. Do this by configuring the HTTPS Inspection rulebase to inspect a single subnet or few subnets and enabling HTTPS Inspection on a single Security Gateway at first. then expand to cover all Security Gateways and networks. > > #### (Part 1 - 3) Introduction: Initial configuration {#Introduction - Initial configuration} > > Show / Hide this section > > For more information, see the [Threat Prevention Administration Guide](https://support.checkpoint.com/product/417) for the relevant version \> chapter "HTTPS Inspection". ### (Part 2) Best Practices {#Best Practices} > #### (Part 2 - 1) Best Practices: Configuring inbound certificates {#Best Practices - Configuring inbound certificates} > > Show / Hide this section > > When importing an internal server's certificate for inbound traffic inspection, it is necessary to include all the intermediate CAs of the chain in the \*.p12 file. > > > > Inclusion of only the server certificate may cause some browsers to warn about untrusted sites, since some browsers are unable to fetch and validate the complete certificate chain. > > > > Management Server versions R82 and higher: > > > > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk108202/CERT_INBOUND202411041242211.png) > > > > Management Server versions R81.20 and lower: > > > > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk108202/Configuring_Certificates202107291546151.png) > > > > **Note:** > > > **Making sure all intermediate certificates in the chain are signed with SHA-256 to avoid browser warnings** > > > > > > For both inbound and outbound HTTPS Inspection, validate that all intermediate certificates in the chain are signed with SHA-256 (or higher) algorithm. > > > > > > Otherwise, browsers may warn (either by icon next to the URL, or in other ways) that the connection is not secure enough. > > > This limitation applies only to intermediate certificates in the chain, and not to root CAs. > > #### (Part 2 - 2) Best Practices: Configuring outbound certificates {#Best Practices - Configuring outbound certificates} > > Show / Hide this section > > The outbound CA certificate is used to sign the certificates generated by the Security Gateway. As the Security Gateway functions as a Man-In-The-Middle (MITM) during HTTPS Inspection, it must sign certificates on-the-fly for outbound traffic. > > > > This requires a CA certificate with the appropriate authority to issue certificates. Without a CA certificate, the Security Gateway cannot sign certificates, and Outbound HTTPS Inspection cannot work. > > > > It is imperative to import a CA certificate. Importing a non-CA certificate will result in client web browsers refusing the TLS connection. > > > > **Note** - Starting from R82, you can create or import more than one outbound CA certificate and manage them in SmartConsole. > > > > **Best Practice:** > > > **We recommend to configure the Security Gateway's outbound CA as a subordinate CA under an existing organizational CA.** > > > > > > This allows clients to automatically inherit the trust relationship from the root CA, eliminating the need to distribute the Security Gateway's CA certificate separately. > > > > > > Instead, only the root CA certificate of the organization needs to be deployed to clients. > > > > > > This setup with a subordinate CA simplifies the certificate management. > > > > > > When it is necessary to replace the outbound CA certificate on the Security Gateway, the trust chain remains intact, as it relies on the root CA. > > > > > > This minimizes administrative overhead and ensures a seamless transition during certificate updates. > > > > > > **Steps to configure the Security Gateway's Outbound CA as a Subordinate CA:** > > > > > > **Note** - If you already deployed an organization CA certificate, then start from Step "c". > > > > > > 1. Generate a root CA certificate for your organization using your chosen Certificate Authority tool (e.g., OpenSSL, Microsoft CA, etc.). This root CA will serve as the trusted anchor for all subordinate CAs. > > > > > > 2. Deploy the root CA certificate to all client devices to establish a trust relationship. This ensures clients recognize and trust any certificates issued by the subordinate CA. > > > > > > 3. Generate a certificate signing request (CSR) for the subordinate CA. Use the root CA to sign this CSR, creating a subordinate CA certificate. Ensure the subordinate CA certificate includes the necessary extensions for signing other certificates (e.g., Basic Constraints and Key Usage). > > > > > > 4. In SmartConsole, import the subordinate CA certificate. > > > > > > * Management Server versions R82 and higher: > > > > > > From the left navigation panel, click **Security Policies** \> in the middle panel, in the **HTTPS Inspection** section, click **Outbound Policy** \> from the top toolbar, click **Outbound Certificates** \> click **Import** \> select the subordinate CA certificate \> enter the password \> click **OK**. > > > > > > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk108202/outbound_cert202410291544361.png) > > > * Management Server versions R81.20 and lower: > > > > > > From the left navigation panel, click **Manage \& Settings** \> **Blades** \> in the **HTTPS Inspection** section, click **Configure in SmartDashboard** \> on the **HTTPS Inspection** tab, click the **Gateways** page \> at the bottom of the page, on the button **Renew Certificate** , click the downward arrow \> click **Import Certificate from file** \> select the subordinate CA certificate \> enter the password \> click **OK** \> in the top left corner, click **Save** (the diskette icon) \> close the SmartDashboard window. > > > > > > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk108202/CA_Creation202107291548262.png) > > > > > > **Notes** > > > * You can also import this certificate in the Security Gateway object on the **HTTPS Inspection** page \> in the section **Step 1**. > > > > > > * When importing a certificate, it is necessary to include all the intermediate CAs of the chain in the `*.p12` file. Inclusion of only the server certificate or the intermediate CA certificate may cause some web browsers to warn about untrusted sites because some web browsers are unable to fetch and validate the complete certificate chain. > > > > > > 5. Install the Access Control policy on the Security Gateway object to apply the new outbound CA configuration. > > > > **Note:** > > > **Making sure all intermediate certificates in the chain are signed with SHA-256 to avoid browser warnings** > > > > > > For both inbound and outbound HTTPS Inspection, validate that all intermediate certificates in the chain are signed with SHA-256 (or higher) algorithm. > > > > > > Otherwise, browsers may warn (either by icon next to the URL, or in other ways) that the connection is not secure enough. > > > This limitation applies only to intermediate certificates in the chain, and not to root CAs. > > #### (Part 2 - 3) Best Practices: Creating the HTTPS Inspection Rule Base {#Best Practices - Creating the HTTPS Inspection Rule Base} > > Show / Hide this section > > 1. **Blocked Connections:** > > If a connection is terminated based on the access rule-base, the HTTPS Inspection rule becomes irrelevant. Whether you have added a bypass rule or an inspection rule, in both cases, the connection is ultimately dropped due to the match with the access policy's default drop rule. > > > > 2. **What to Inspect** > > > > We recommend to inspect HTTPS traffic from desktop browsers (Outbound HTTPS Inspection). Users may choose to bypass certain categories due to privacy considerations. > > > > Starting from R82, a default outbound rule is added to bypass finance, health and government categories in order to protect privacy rights. > > > > Non-browser HTTPS applications tend to trust their own root CA store and not to trust the certificate generated by the Security Gateway (examples: Google Drive, DropBox). > > > > In addition, non-browser HTTPS applications may use non-standard SSL and therefore cannot be inspected by the Security Gateway. > > > > These limitations are not specific to Check Point. > > > > It is possible to bypass these connections by Server IP address (when available), Client IP address (if there are few clients using these applications), or user identity. > > > > In cases the server uses standard SSL, bypass according to Category/URL can also be used. > > > > This is the recommended order for HTTPS Inspection Policy (Top-to-Down): > > 1. IP-based Bypass rules with no site/category defined > > For more information, see [sk163595](https://support.checkpoint.com/results/sk/sk163595). > > 2. Bypass rules with site/category defined > > For more information, see [sk165094](https://support.checkpoint.com/results/sk/sk165094). > > 3. Inspect rules > > 3. **Inspection of sites with a multi-category certificate** > > > > HTTPS Inspection bypass decisions are based on the server's certificate and client request. > > > > It is important to note that there are servers that issue a single certificate for several domains from different categories (Search Engines / Portals, Media Sharing, etc.). > > > > For example, see the Google certificate below: > > > > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk108202/1.png) > > > > 4. **Services in the HTTPS Inspection rules** > > > > In the HTTPS Inspection rule, in the **Services** column, we recommend to keep the default service object "*HTTPS default services*". > > > > If it is necessary to add other services, [consult Check Point Support](https://www.checkpoint.com/support-services/contact-support/). > > > > **Always select specific service objects in the 'Services' column**. > > > > If you remove all services from this column, the Security Gateway starts to inspect all TCP traffic. As a result, CPU load increases. > > 5. **Bypassing Based on Client-Side Failures** > > > > When client-side issues occur (for example, a connection is dropped because of a certificate-pinned application), future connections will be automatically bypassed. > > > > We recommend to identify the root cause of such issues and create an HTTPS Inspection Bypass rule for the specific application or destination. Alternatively, you can create an Access Control rule to block the application, if necessary. > > > > Client-side issues can also arise if the HTTPS Inspection Outbound CA is not deployed for the client's web browser. In such cases, properly deploying the CA will solve the issue. > > > > To allow bypass without impact on user experience or privacy, it is necessary to determine the site's category without performing TLS decryption. > > > > To accomplish this, the site's category is resolved according to the SAN (Subject Alternative Name) or CN (Common Name) fields of server's certificate, and the SNI (Server Name Indication) TLS extension sent by the client. > > > > When the SNI extension isn't provided by the client, users should take into account that connections to servers that present the same server certificate may be matched to the same category. > > #### (Part 2 - 4) Best Practices: Internet connection {#Best Practices - Internet connection} > > Show / Hide this section > > Make sure the Security Gateway is connected to the Internet, either directly or through a proxy. > > > > Proxy can be defined in the Security Gateway properties, or in the *Global Properties*. > > > > If there is no Internet connection, then CRL fetch and intermediate CA fetch will fail (this will be logged). > > > > The inspection will take place; however, URL-based or Category-based bypassing will not work. > > > > **Note:** The CRL verifications are performed in the background asynchronously while matching the security policy (this mimics the behavior of the major web browsers). > > > > Untrusted certificates and lack of CRLs can be configured as reasons to drop the connection: > > > > Management Server versions R82 and higher: > > > > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk108202/server202410311348261.png) > > > > Management Server versions R81.20 and lower: > > > > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk108202/Internet_Connection202107291557321.png) > > > > **Note about Bridge interfaces:** In order for inspection to work properly, CRL validation is required. > > > > Therefore the Security Gateway must have an Internet connection in addition to the bridge interfaces. > > #### (Part 2 - 5) Best Practices - Monitor TLS connections {#Best Practices - Monitor TLS connections} > > Show / Hide this section > > Starting from R82, the HTTPS Inspection Statistics View allows you to monitor TLS traffic, providing clear view of Bypass and Inspect decisions. For more details, refer to [How to use the HTTPS Inspection Statistics view](https://support.checkpoint.com/results/sk/sk182172). > ### (Part 3) Additional Information {#Additional Information} > #### (Part 3 - 1) Additional Information: Perfect Forward Secrecy Cipher Suites {#Additional Information - Perfect Forward Secrecy Cipher Suites} > > Show / Hide this section > > * **Perfect Forward Secrecy (PFS) - introduction** > > > > [Perfect Forward Secrecy (PFS)](https://en.wikipedia.org/wiki/Forward_secrecy) is a key agreement method that saves the need of transferring shared secrets on the wire, thus guaranteeing secrecy in the future, even if the traffic is recorded in the present. > > PFS is widely used in TLS and IKE/IPsec. > > * **Perfect Forward Secrecy (PFS) - ECDHE** > > > > [Diffie-Hellman (DH)](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) has been the traditional PFS algorithm. > > > > [Elliptic curve Diffie-Hellman (ECDH)](https://en.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman) is a modern PFS algorithm based on Elliptic Curve computations. > > > > The same security level of Diffie-Hellman is achieved with much shorter keys in ECDH, so performance is much better. > > > > ECDHE is a protocol that uses [Ephemeral](https://en.wikipedia.org/wiki/Ephemeral_key) ECDH keys. > > > > Some Web servers only accept PFS ciphers (DHE, ECDHE). > > > > ECDHE is fully supported in these versions of Security Gateway (ID 01418393): > > * R77.30 (ID 01467522) and higher > > * R77.20 with [Jumbo Hotfix Accumulator](https://support.checkpoint.com/results/sk/sk101975) - *Take_143* and higher (ID 01546352). > > > > For more information, refer to: > > > > * [sk65123 - HTTPS Inspection FAQ](https://support.checkpoint.com/results/sk/sk65123) > > * [sk104562 - Supported cipher suites for HTTPS Inspection](https://support.checkpoint.com/results/sk/sk104562) > > * [sk1653594 - What's new in HTTPS Inspection starting from R80.20](https://support.checkpoint.com/results/sk/sk163594) > > > > **Note:** Some web servers do not accept any of the Security Gateway's proposals. > > > > Connections to such web servers will fail without a log. > > > > If you encounter such issue, then [contact Check Point Support](http://www.checkpoint.com/support-services/contact-support/index.html) for assistance. > > #### (Part 3 - 2) Additional Information: Certificate-pinned Applications {#Additional Information - Certificate-pinned Applications} > > Show / Hide this section > > Certificate-pinned applications, which are often non-browser clients, can face challenges with HTTPS Inspection. These certificate-pinned applications only trust specific server certificates. Therefore, importing the Security Gateway's CA certificate into the trust store on the client's operating system may not be enough to gain their trust. This can result in warnings or blocked traffic from these certificate-pinned applications. > > > > To enhance security, we recommend to either restrict the traffic of such certificate-pinned applications using the Access Control policy or create HTTPS Inspection Bypass rules for traffic originating from devices that use these certificate-pinned applications or for the specific services, on which these applications depend. > > > > Starting from R80.40, an Updatable Object is available to simplify the process of bypassing these certificate-pinned applications. Each applicable Updatable Object includes a list of HTTPS services known to be used in pinned-certificate scenarios. Additionally, a list of well-known HTTPS services used by popular programs and applications has been introduced and is recommended for HTTPS Inspection Bypass. > > > > Starting from R82, several new features were added to further address the challenges posed by certificate-pinned applications: > > > > * Full Fail-Open Mode: Automatically detects failures in the HTTPS Inspection process due to client-side issues like pinned certificates. When a failure is detected, the connection is added to an exception list, ensuring zero connectivity issues for end-users. > > * Allow Lists: In addition to the well-known HTTPS services, this list includes known certificate-pinned applications identified through learning and analyzing similar connection behaviors, allowing users to decide whether to bypass them. > > > > For more information, refer to: > > > > * [sk163595 - HTTPS Inspection bypass list object](https://support.checkpoint.com/results/sk/sk163595) > > * [sk131852 - Updatable Objects in R80.20 and higher (general information about Updatable Objects)](https://support.checkpoint.com/results/sk/sk131852) > > #### (Part 3 - 3) Additional Information: Update Services {#Additional Information - Update Services} > > Show / Hide this section > > Update services (such as Microsoft updates) are *implicitly* bypassed in the HTTPS Inspection rulebase. > > #### (Part 3 - 4) Additional Information: Traffic over QUIC or HTTP/3 {#Additional Information - Traffic over QUIC or HTTP/3} > > Show / Hide this section > > Inspecting traffic over QUIC or HTTP/3 is supported starting from R82. > > > > In Security Gateway versions R81.20 and lower, we recommend to configure clients to use TLS instead, or reject such traffic to force them to use TLS. > > > > For more information, refer to: > > > > [sk111754 - HTTPS traffic to Google services (over QUIC) from Chrome cannot be inspected by HTTPS inspection rules](https://support.checkpoint.com/results/sk/sk111754) > > #### (Part 3 - 5) Additional Information: Categorized HTTPS vs. HTTPS Inspection {#Additional Information - Categorized HTTPS vs. HTTPS Inspection} > > Show / Hide this section > > The "Categorize HTTPS websites" feature (in combination with URL Filtering) lets you categorize HTTPS sites without having to enable HTTPS Inspection. > > > > When HTTPS Inspection is enabled, it also allows categorization for connections that are bypassed according the HTTPS Inspection rule base. > > > > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk108202/Categorized_HTTPS202107291616391.png) > > > > This feature does not perform inspection on the traffic and is only used to categorize sites so that URL Filtering rules can be enforced correctly. > > > > Policies based on feature should consider that the confidence level in categorization is lower than that of HTTPS Inspection. > > > > Similarly to HTTPS Inspection, the site's category is resolved according to the SAN (Subject Alternative Name) or CN (Common Name) fields of server's certificate, and the SNI (Server Name Indication) TLS extension sent by the client. > > > > Note: Just like with HTTPS Inspection, make sure the Security Gateway is connected to the Internet, either directly or through a proxy. > > > > A proxy server can be defined in the Security Gateway properties, or in the Global Properties. > > > #### (Part 3 - 6) HTTPS Inspection support for Post-Quantum Cryptography (PQC) {#Additional Information - HTTPS Inspection support for Post-Quantum Cryptography (PQC)} > > Show / Hide this section > > To help protect against "Harvest Now, Decrypt Later" cryptographic attacks, major web browsers have introduced support for quantum-safe algorithms, following recommendations by the National Institute of Standards and Technology (NIST). > > This support is implemented in TLS 1.3 using a hybrid key exchange mechanism, which combines a classical public key cryptography algorithm (for example, ECDHE) with a post-quantum cryptography algorithm. Early implementations used CRYSTALS-Kyber algorithms as the quantum-safe component. In August 2024, NIST finalized the standardization of quantum-safe algorithms under the name ML-KEM and published it as [FIPS 203](https://csrc.nist.gov/pubs/fips/203/final). For more information, see [sk182846](https://support.checkpoint.com/results/sk/sk182846). > > ### (Part 4) Performance {#Performance} > > Show / Hide this section > > HTTPS Inspection creates additional load on Security Gateway's CPU and increased RAM usage due to these reasons: > > > > TLS termination, encrypt/decrypt and active TCP termination. > > > > Additional traffic is inspected by security blades. > > > > In general, the more blades and security features, the higher the additional load. > > ### (Part 5) Debug {#Debug} > > > #### (Part 5 - 1) Debug: Notes {#Debug - Notes} > > > > Show / Hide this section > > > * Always schedule a maintenance window to run any debug session. > > > > > > * [Contact Check Point Support](http://www.checkpoint.com/support-services/contact-support/index.html) to get exact debug instructions specific to your case. > > > > > > * In a cluster environment, debug must be collected on *all* members of the cluster. > > > > > > * To decrease the load on Security Gateway's CPU, the kernel debug can be started only on specific CoreXL FW Instances only. > > > > > > The safest way to do so is by starting the kernel debug on CoreXL FW Instance 0: > > > > > > *# fw ctl debug 0* > > > > > > *# fw ctl debug -buf 32000* > > > > > > *# fw ctl debug -m MODULE + FLAGS* > > > > > > *# fw **-i 0** ctl kdebug -T -f \> /var/log/debug.txt* > > > * Refer to [Security Gateway Administration Guide](https://support.checkpoint.com/product/73#q=%22Security%20Gateway%20Guide%22&f-commonsource=C.%20Documentation) for your version - section "Kernel Debug Modules and Debug Flags". > > > > #### (Part 5 - 2) Debug: WSTLSD daemon {#Debug - WSTLSD daemon} > > > > Show / Hide this section > > > WSTLSD daemon handles SSL handshake for HTTPS Inspected connections. > > > > > > Refer to [sk105559 - How to debug WSTLSD daemon](https://support.checkpoint.com/results/sk/sk105559). > > > > #### (Part 5 - 3) Debug: Firewall debug {#Debug - Firewall debug} > > > > Show / Hide this section > > > **Important Note:** This kernel debug can cause very high load on Security Gateway's CPU. > > > > > > Schedule a maintenance window. > > > > > > 1. Prepare the debug: > > > > > > *\[Expert@HostName:0\]# fw ctl debug 0* > > > > > > *\[Expert@HostName:0\]# fw ctl debug -buf 32000* > > > > > > *\[Expert@HostName:0\]# fw ctl debug -m fw + conn drop cptls* > > > > > > *\[Expert@HostName:0\]# fw ctl debug -m mux + tls* > > > > > > From R80.40, you should also use: > > > > > > \[Expert@HostName:0\]# fw ctl debug -m crypto + all > > > 2. Verify the debug: > > > > > > *\[Expert@HostName:0\]# fw ctl debug -m fw* > > > Output should show debugging buffer size 32000KB and all the debugging options enabled in the previous step. > > > 3. Start the debug: > > > > > > *\[Expert@HostName:0\]# fw ctl kdebug -T -f \> /var/log/debug.txt* > > > 4. Capture the involved traffic: > > > > > > Refer to [sk30583 - What is FW Monitor?](https://support.checkpoint.com/results/sk/sk30583). > > > > > > It might also be required to capture the traffic with TCPdump. > > > 5. Replicate the issue: > > > > > > Make sure the issue was replicated. > > > > > > Collect all the relevant screenshots / logs that show the issue. > > > 6. Stop the debug: > > > > > > Press CTRL+C and run > > > > > > *\[Expert@HostName:0\]# fw ctl debug 0* > > > 7. Collect these files: > > > > > > * */var/log/debug.txt* > > > * */var/log/messages\** > > > * traffic capture(s) > > > * CPinfo file from the involved Security Gateway(s) / Cluster members > > > * CPinfo file from the involved Security Management Server / Domain Management Server > > > > #### (Part 5 - 4) Debug: HTTPS Inspection rulebase matching {#Debug - HTTPS Inspection rulebase matching} > > > > Show / Hide this section > > > **Important Note:** This kernel debug can cause very high load on Security Gateway's CPU. > > > > > > Schedule a maintenance window. > > > > > > 1. Prepare the debug: > > > > > > *\[Expert@HostName:0\]# fw ctl debug 0* > > > > > > *\[Expert@HostName:0\]# fw ctl debug -buf 32000* > > > > > > *\[Expert@HostName:0\]# fw ctl debug -m fw + conn drop* > > > > > > *\[Expert@HostName:0\]# fw ctl debug -m NRB all* > > > > > > *\[Expert@HostName:0\]# fw ctl debug -m WS + connection info module pkt_dump policy session spii ssl_insp vs* > > > 2. Verify the debug: > > > > > > *\[Expert@HostName:0\]# fw ctl debug -m fw* > > > > > > *\[Expert@HostName:0\]# fw ctl debug -m NRB* > > > > > > *\[Expert@HostName:0\]# fw ctl debug -m WS* > > > Output should show debugging buffer size 32000KB and all the debugging options enabled in the previous step. > > > 3. Start the debug: > > > > > > *\[Expert@HostName:0\]# fw ctl kdebug -T -f \> /var/log/debug.txt* > > > 4. Capture the involved traffic: > > > > > > Refer to [sk30583 - What is FW Monitor?](https://support.checkpoint.com/results/sk/sk30583). > > > > > > It might also be required to capture the traffic with TCPdump. > > > 5. Replicate the issue: > > > > > > Make sure the issue was replicated. > > > > > > Collect all the relevant screenshots / logs that show the issue. > > > 6. Stop the debug: > > > > > > Press CTRL+C and run > > > > > > *\[Expert@HostName:0\]# fw ctl debug 0* > > > 7. Collect these files: > > > > > > * */var/log/debug.txt* > > > * */var/log/messages\** > > > * traffic capture(s) > > > * CPinfo file from the involved Security Gateway(s) / Cluster members > > > * CPinfo file from the involved Security Management Server / Domain Management Server > > ### (Part 6) Related documentation {#Related documentation} > > Show / Hide this section > > * [Threat Prevention Administration Guide](https://support.checkpoint.com/product/417) for your version - section "Configuring HTTPS Inspection" > > > > * [Security Gateway Administration Guide](https://support.checkpoint.com/product/73#q=%22Security%20Gateway%20Guide%22&f-commonsource=C.%20Documentation) for your version - section "Kernel Debug Modules and Debug Flags" > > ### (Part 7) Related solutions {#Related solutions} > > Show / Hide this section > > **Note:** These articles require "Advanced" [access level](http://www.checkpoint.com/support-services/support-plans/) or higer. > > > > * Configuration > > > > * [sk182679 - HTTPS Inspection Learning Mode recommendation](https://support.checkpoint.com/results/sk/sk182679?server=us) > > * [sk182172 - How to use the HTTPS Inspection Statistics view](https://support.checkpoint.com/results/sk/sk182172?server=us) > > * [sk180507 - HTTPS traffic issues because some Trusted CA certificates are disabled on the Management Server](https://support.checkpoint.com/results/sk/sk180507?server=us) > > * [sk64521 - How to update the Trusted Certificate Authorities (CAs) list for HTTPS Inspection and HTTPS Categorization](https://support.checkpoint.com/results/sk/sk64521) > > * [sk65123 - HTTPS Inspection FAQ](https://support.checkpoint.com/results/sk/sk65123) > > * [sk104717 - HTTPS Inspection Enhancements in R77.30](https://support.checkpoint.com/results/sk/sk104717) > > * [sk101223 - MultiCore Support for SSL](https://support.checkpoint.com/results/sk/sk101223) > > * [sk104562 - Supported cipher suites for HTTPS Inspection](https://support.checkpoint.com/results/sk/sk104562) > > * [sk108654 - How to control support for SSLv2 handshake in HTTPS Inspection](https://support.checkpoint.com/results/sk/sk108654) > > * [sk108641 - How to Renew or Import a new HTTPS Inspection certificate](https://support.checkpoint.com/results/sk/sk108641) > > * [sk90840 - HTTPS Inspection is not supported for IPv6 traffic](https://support.checkpoint.com/results/sk/sk90840) > > * [sk106996 - "HTTP Strict Transport Security" (HSTS) header handling in HTTPS Inspection](https://support.checkpoint.com/results/sk/sk106996) > > * [sk74000 - Disabling TLS 1.1 and 1.2 in Portals and HTTPS Inspection](https://support.checkpoint.com/results/sk/sk74000) > > * [sk97638 - Check Point Processes and Daemons](https://support.checkpoint.com/results/sk/sk97638) > > * Troubleshooting > > > > * [sk112066 - How to troubleshoot issues with HTTPS Inspection](https://support.checkpoint.com/results/sk/sk112066) > > * [sk98348 - Best Practices - Security Gateway Performance](https://support.checkpoint.com/results/sk/sk98348) > > * [sk108653 - Security Gateway with enabled HTTPS Inspection crashes repeatedly](https://support.checkpoint.com/results/sk/sk108653) > > * [sk92888 - Enabling HTTPS Inspection causes some applications to stop working](https://support.checkpoint.com/results/sk/sk92888) > > * [sk112214 - Several HTTPS web sites and applications might not work properly when HTTPS Inspection is enabled on Security Gateway](https://support.checkpoint.com/results/sk/sk112214) > > * [sk113792 - HTTPS Inspection does not block HTTPS sites whose FQDN does not match the "Issued to" field in their certificate](https://support.checkpoint.com/results/sk/sk113792) > > * [sk107744 - Unable to access some HTTPS sites after enabling HTTPS Inspection "Probe Bypass" mechanism](https://support.checkpoint.com/results/sk/sk107744) > > * [sk108894 - Difficulties in connecting to untrusted sites when both HTTPS Inspection and CoreXL Dynamic Dispatcher are enabled](https://support.checkpoint.com/results/sk/sk108894) > > * [sk64166 - HTTPS Inspection logs are misleading](https://support.checkpoint.com/results/sk/sk64166) > > * [sk108187 - There are no logs for HTTPS Inspection, although it is enabled and configured for inbound inspection.html](https://support.checkpoint.com/results/sk/sk108187) > > * [sk101166 - HTTPS Inspection ignores HTTPS traffic via proxy with authentication](https://support.checkpoint.com/results/sk/sk101166) > > * [sk92839 - HTTPS Inspection and 'X-Forward-For' (XFF) HTTP header when inspecting proxy traffic](https://support.checkpoint.com/results/sk/sk92839) > > * [sk96125 - Windows Update fails through Security Gateway with enabled HTTPS Inspection](https://support.checkpoint.com/results/sk/sk96125) > > * [sk98025 - HTTPS inspection with 3rd party certificate shows browser error](https://support.checkpoint.com/results/sk/sk98025) > > * [sk92654 - HTTPS traffic is not inspected although HTTPS Inspection is enabled and Identity Awareness is used](https://support.checkpoint.com/results/sk/sk92654) > > * [sk101791 - HTTPS Inspection "Bypass" rule that contains Dynamic Object does not work](https://support.checkpoint.com/results/sk/sk101791) > > * [sk93184 - Users do not receive UserCheck page for blocked HTTPS content](https://support.checkpoint.com/results/sk/sk93184) > > * [sk85640 - UserCheck interaction page is not displayed for HTTPS connections that pass through Proxy](https://support.checkpoint.com/results/sk/sk85640) > > * [sk107325 - No access to HTTPS sites from Firefox when HTTPS Inspection is enabled](https://support.checkpoint.com/results/sk/sk107325) > > * [sk102721 - UserCheck page is displayed twice when Application Control and HTTPS Inspection are enabled, and user is redirected from HTTP to HTTPS web site](https://support.checkpoint.com/results/sk/sk102721) > > * [sk104095 - RC4 cipher is allowed for Inbound HTTPS inspection](https://support.checkpoint.com/results/sk/sk104095) > > * [sk106296 - Not able to connect to HTTPS web sites that use ECDHE cipher suites after upgrading to R77.30](https://support.checkpoint.com/results/sk/sk106296) > > * [sk105538 - Security Gateway with enabled HTTPS Inspection might crash during high traffic load](https://support.checkpoint.com/results/sk/sk105538) > > * Debug > > > > * [sk105559 - How to debug WSTLSD daemon](https://support.checkpoint.com/results/sk/sk105559) > > ### (Part 8) Revision history {#Revision history} > > Show / Hide this section > > > > |--------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| > > | Date | Description | > > | 06 Nov 2024 | * "Best Practices" section - "(Part 2 - 1) Best Practices: Configuring certificates" - split into two sections: * (Part 2 - 1) Best Practices: Configuring inbound certificates * (Part 2 - 2) Best Practices: Configuring outbound certificates | > > | 06 Nov 2024 | * "Best Practices" section - "(Part 2 - 2) Best Practices: Creating the HTTPS Inspection Rule Base" - add the step "Bypassing Based on Client-Side Failures" * "Additional Information" section - "(Part 3 - 2) Additional Information: Certificate-pinned Applications" - updated the entire text | > > | 28 Feb 2023 | * Improved formatting of the article * "Best Practices" section - "(Part 2 - 2) Best Practices: Creating the HTTPS Inspection Rule Base" - added "C. Services in the HTTPS Inspection rules" | > > | 19 June 2017 | * "Introduction" section - added "Content Awareness" to the list of Software Blades that support HTTPS Inspection | > > | 21 Mar 2017 | * "Introduction" section - "(Part 1 - 1) Outbound HTTPS Inspection" - added a note about certificate being validated only in case of inspection * "Best Practices" section - "(Part 2 - 3) Internet connection" - added a note about CRL verifications being performed in the background * "Additional Information" section - "(Part 3 - 4) Categorized HTTPS vs. HTTPS Inspection" - added a note about certificate being validated only in case of inspection | > > | 14 July 2016 | * "Related solutions" section - added related solution | > > | 22 May 2016 | * "Introduction" section - added "Threat Emulation" blade to the list of Software Blades that support HTTPS Inspection | > > | 31 Jan 2016 | * "Best Practices" section - "(Part 2 - 1) - B) CA creation/import" - added relevant steps for best practice, fastest deployment, and best security | > > | 10 Dec 2015 | * "Related solutions" section - added related solutions | > > | 18 Nov 2015 | * "Performance" section - added related solution (for Check Point Partners) | > > | 13 Nov 2015 | * "Related solutions" section - added related solutions | > > | 12 Nov 2015 | * First release of this article | --- # Agent Instructions This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products. ## Navigating This Knowledge Base - **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt) - **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml) - **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}` - **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content