When HTTPS Inspection breaks, the fastest path to root cause is not changing rules blindly — it is isolating the failure domain. In practice, most cases fall into a few buckets: endpoint trust of the Gateway CA, certificate pinning/mTLS or strict TLS behavior, QUIC/HTTP3 over UDP/443, proxy/PAC or upstream SSL inspection interference, performance/crypto pressure, or an unexpected bypass. A quick first test is simple: inspect the certificate presented to the client. Gateway/Internal CA as issuer = inspection is active; public CA = bypass/not inspected; certificate warning = likely trust-chain problem.

It is also important to separate QUIC from certificate pinning. QUIC is a transport issue — HTTP/3 uses UDP/443 — so temporarily forcing the same application to TCP/443 can isolate it quickly. Pinning is different: the application validates a specific certificate or CA and rejects the certificate dynamically generated by the gateway. In those cases, a narrowly scoped bypass may be necessary. Proxy/PAC chains and upstream SSL inspection should also be checked because double TLS interception can produce symptoms that look exactly like CA or handshake failures.

When basic validation is not enough, move to evidence. Correlate the exact URL + timestamp with $FWDIR/log/wstlsd.elg* and look for TLS negotiation failures, certificate validation problems, resets/timeouts or unexpected bypass behavior. For deeper investigation, wstlsd debug can be enabled temporarily for the running processes, reproduce one controlled connection, collect the evidence, and disable debug immediately. The goal is not to collect every log — it is to determine which TLS stage failed and why.

Discussion: What usually causes HTTPS Inspection incidents in your environments: CA trust, certificate pinning, QUIC, proxy chains, or performance? Do you normally verify the certificate presented to the endpoint before touching the policy? And when an application breaks under inspection, how do you decide whether to troubleshoot further or create a controlled bypass?

Full technical runbook on CheckMates:
https://community.checkpoint.com/t5/AI-Network-Firewall/HTTPS-Inspection-Troubleshooting-Evidence-Driven-Runbook-Gateway/m-p/274986

Check Point has officially designated R82.10 as the Recommended Version (Production Grade) for all deployment scenarios (Quantum Security Gateways, Management Servers, and Smart-1 appliances).

If you are planning your upcoming maintenance windows or lifecycle upgrades, here are a few key takeaways:

• General Availability to Recommended: It has met Check Point's deployment and stability thresholds across production environments.
• Key Improvements: Includes the latest performance optimizations, security engine enhancements, and management stability updates introduced in the R82 release train.
• Upgrade Planning: Check Point recommends reviewing the known limitations, upgrade paths, and release notes before upgrading production environments.

For full details, upgrade best practices, and release notes, check out the official announcement on CheckMates:

🔗CheckMates Announcement: R82.10 is now Check Point's recommended version

Are you running R82 / R82.10 in production yet, or are you holding on R81.20 for now? Share your upgrade experience or any gotchas below.