5.8 HTTPS Inspection

Why HTTPS Inspection Exists

Most modern web traffic is HTTPS. Without decryption, the gateway can see only the SNI hostname in the TLS ClientHello and the server certificate — not the URL path, request body, response body, or transferred files. URLF is limited to hostname categorization, and AV, IPS, Anti-Bot, and Threat Emulation are blind to the encrypted payload.

HTTPS Inspection decrypts HTTPS at the gateway, passes the cleartext to TP blades for inspection, then re-encrypts the traffic for the next leg. The user and the upstream server each see a working HTTPS session; the gateway inspects the content in between.

CCSA expects you to know why it exists, the outbound/inbound distinction, the CA certificate requirements, and the bypass concept.

Outbound vs Inbound Inspection

HTTPS Inspection has two modes that are conceptually distinct.

Outbound Inspection

Outbound inspection applies to traffic where the client is internal and the server is external — users browsing the internet. The gateway must terminate the user's TLS session and establish a new TLS session to the upstream server.

To do this without browser warnings, the gateway presents the user a certificate signed by an outbound CA that the gateway controls. The user's browser must trust that CA. The outbound CA is generated on the Security Management Server and distributed to client trust stores via Group Policy, MDM, or manual install. The user sees a certificate signed by the gateway's outbound CA; the upstream server sees the gateway as the client. The gateway decrypts and re-encrypts both legs.

Inbound Inspection

Inbound inspection applies to traffic where the client is external and the server is internal — outsiders connecting to a published server behind the gateway. The gateway uses the original server's certificate to present to the external client (via SNI forwarding or by holding the server's private key on the gateway). The internal server sees the gateway as the client; the gateway decrypts and re-encrypts both legs.

Inbound inspection requires the gateway to have access to the server's certificate and private key, or to dynamically generate a certificate for the server.

CA Certificate Requirements

The CA model is the part CCSA candidates most often get wrong:

• Outbound inspection requires a CA that client devices trust. If the CA is not trusted, users see a certificate warning on every HTTPS site. The CA is generated on the Security Management Server and distributed to clients.
• Inbound inspection does not require client trust of a new CA because the gateway uses the original server's real certificate — the external client already trusts the public CA that signed it.
• The outbound CA must be protected. If its private key is compromised, an attacker can sign certificates for any site that the gateway's clients will trust. Keep the CA on the Security Management Server, restrict access, and rotate the key per Check Point guidance.

A common CCSA scenario: users report certificate warnings on every HTTPS site after HTTPS Inspection is enabled. The cause is the outbound CA not being trusted by clients; the fix is to distribute the CA to client trust stores.

Bypass and Privacy

Not all HTTPS traffic should be inspected. Common bypass reasons:

• Banking, health, and government sites — privacy and regulatory concerns.
• Certificate-pinned sites and apps — pinning prevents the gateway from impersonating the site; inspection would break the connection. Many mobile apps use pinning.
• Internal CA-signed sites — sites whose certificates the gateway does not trust.

HTTPS Inspection maintains a bypass list of URLs, categories, or sites the gateway will not inspect. The gateway still proxies the connection but does not decrypt it. For bypassed traffic, TP blades that depend on the cleartext payload cannot run; URLF can still categorize by SNI, but AV, IPS, Anti-Bot, and Threat Emulation cannot inspect the content. The CCSA expects you to recognize that bypass is required for privacy/legal compliance and for technical compatibility with pinned apps, and that bypassed traffic is not fully inspectable.

HTTPS Inspection as an Ordered Layer

HTTPS Inspection is its own ordered layer. The layer's rules decide which traffic is inspected and which is bypassed. A typical two-rule layer:

The first matching rule wins. Bypassed traffic is proxied but not decrypted; inspected traffic is decrypted and passed to TP.

Performance and Sizing

Decryption is computationally expensive. A gateway that inspects a large volume of HTTPS will see significant CPU and memory load. Bypassing categories that do not need inspection reduces load. A common scenario: a customer enabled HTTPS Inspection on a small gateway and now sees high CPU. The recommended response is to scope inspection more narrowly (bypass some categories, only inspect specific user groups) rather than disabling HTTPS Inspection entirely.

Common CCSA Scenarios

Typical HTTPS Inspection questions: identify why HTTPS Inspection is needed (to let TP blades inspect the encrypted payload); distinguish outbound (gateway-controlled CA, clients must trust) from inbound (original server cert); identify the cause of certificate warnings after enabling HTTPS Inspection (outbound CA not trusted); recognize the role of the bypass list (privacy, legal, pinning); and recognize HTTPS Inspection as its own ordered layer with first-match evaluation.

A representative scenario: a company enables HTTPS Inspection and a mobile banking app stops connecting. The cause is certificate pinning — the app refuses the gateway's impersonating certificate. The fix is to add the bank's domain to the bypass list; the trade-off is that TP cannot inspect traffic to that bank, but the app works.