Study guide
5.8 HTTPS Inspection
CCSA R82 — Check Point Certified Security Administrator Study Guide Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Introduction & Architecture
1.1 CCSA R82 Exam Facts 1.2 Standalone vs Distributed Deployment 1.3 Gaia OS, clish and expert Mode 1.4 The SmartConsole Suite 1.5 Secure Internal Communication and the ICA
2 Chapter 2: Security Policy & Access Control
2.1 Policy Packages 2.2 Access Control Policy Overview 2.3 Ordered Layers and First-Match Evaluation 2.4 Inline Layers and Nested Rule Matching 2.5 Access Rules: Fields, Actions, and Track Options 2.6 Implied Rules and Global Properties 2.7 Stealth and Cleanup Rules: Placement and Best Practice 2.8 Hit Count and Policy Install Workflow
3 Chapter 3: Network Address Translation (NAT)
3.1 NAT Overview in Check Point 3.2 Hide NAT (Many-to-One) 3.3 Static NAT (One-to-One) 3.4 Automatic vs Manual NAT and Proxy ARP
4 Chapter 4: Identity Awareness
4.1 Identity Awareness Overview 4.2 Active Directory Query 4.3 Identity Collector 4.4 Identity Agent 4.5 Captive Portal and Access Roles
5 Chapter 5: Threat Prevention
5.1 Threat Prevention Overview 5.2 Application Control 5.3 URL Filtering 5.4 Intrusion Prevention System (IPS) 5.5 Anti-Bot and Anti-Virus 5.6 Threat Emulation and Threat Extraction 5.7 TP Profiles, Best Practice, and Ordered Layers for TP 5.8 HTTPS Inspection
6 Chapter 6: ClusterXL — High Availability, Load Sharing, and Failover
6.1 ClusterXL Overview: Why Clustering, HA vs Load Sharing 6.2 High Availability Mode: Active/Standby, Primary Up vs Active Up 6.3 Load Sharing Modes: Multicast, Unicast (Pivot), and Traffic Distribution 6.4 Cluster Control Protocol (CCP) and State Synchronization 6.5 Failover, Cluster States, and Troubleshooting with cphaprob
7 Chapter 7: VPN, Logs, and Troubleshooting
7.1 Site-to-Site IPsec VPN 7.2 Remote Access VPN 7.3 Encryption Domains and VPN Communities 7.4 Mobile Access Blade 7.5 Logs, Monitor, and SmartEvent 7.6 Backups, Snapshots, and Migrate Export 7.7 fw monitor, fw ctl zdebug, and cpview 7.8 cpinfo and Common Issues
5.8 HTTPS Inspection
Key Takeaways Explain This Topic AI
HTTPS Inspection decrypts HTTPS traffic so that TP blades can inspect the cleartext payload, then re-encrypts it for the upstream or downstream leg.
Outbound inspection (gateway as client-facing CA) requires client devices to trust the gateway's outbound CA certificate.
Inbound inspection uses the original server's certificate; the gateway presents the server cert to the client after re-encryption.
Privacy, legal, and technical constraints drive bypass categories and a bypass list for sites that must not be inspected.
Last updated: July 2026
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:
- Rule Source Destination Action
- 1 Internal users Bypass category (banking, health) Bypass
- 2 Internal users Any Inspect (outbound)
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.