- Products
- Learn
- Local User Groups
- Partners
- More
Step Into the Future of
AI-Powered Cyber Security
What's New in R82.10?
Register HereWhen the Agents Attack
A Live Look at Agentic Exposure Validation
AI Security Masters E8:
Claude Mythos: New Era in Cyber Security
CheckMates Go:
CheckMates Fest
Hi,
Two questions:
1. Is URL Categorization based on SNI or "Application Name" (CN name ?) when the gateway is deciding on witch category destination falls in to?
2. Does the categorization not being done when destination has a untrusted certificate?
Regards,
Anders Larsson
In earlier release (pre-R80.30) only CN was used, now verified SNI is used when available.
Part of the verification process is checking the cert provided by the remote server matches the SNI requested by the client.
HTTPS Inspection actually requires the certificate be signed by a valid CA, not sure this is required merely for categorization.
When this fails for HTTPS Inspection, there are definitely log messages.
In earlier release (pre-R80.30) only CN was used, now verified SNI is used when available.
Part of the verification process is checking the cert provided by the remote server matches the SNI requested by the client.
HTTPS Inspection actually requires the certificate be signed by a valid CA, not sure this is required merely for categorization.
When this fails for HTTPS Inspection, there are definitely log messages.
Thanks for the reply!
If HTTPS Inspection is not being used only URL-categorization, is there any change of how this is categorized for R81.10?
As @PhoneBoy mentioned, with R80.40 and up, we are using a patented SNI validation. As part of it, we request a site certificate and make sure it is valid and corresponds to the rest of web request data: SNI and URL.
The URL categorization is part of this process, and it is done via HTTPS even if you did not enable HTTPSi on your security GW.
So if the certificate is not trusted there is no categorization?
/Anders
Actually, the change was introduced in R80.30 and backported to R80.20 JHF.
I believe SNI Verification requires HTTPS Inspection to be enabled in R80.20 and R80.30, but it is not required in R80.40 and above.
I am pretty sure what phoneboy said is also done by any other major vendors that do https inspection, but thats the gist of it really.
That is not exactly true, I am afraid. I think you misunderstood what PH conveyed 🙂
How so? 🙂
The main differentiator from the rest of the competitors is SNI validation. Instead of taking it for granted, we actually pull the server certificate and compare its details with the SNI data.
This is, or at least was, unique for Check Point when R80.40 was out, and we filed a patent application for it.
Hope this makes sense.
A kk, I see what you mean, makes sense. Though, Im pretty positive that Fortinet and PAN do it nowdays as well.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 27 | |
| 8 | |
| 6 | |
| 5 | |
| 5 | |
| 5 | |
| 5 | |
| 4 | |
| 3 | |
| 3 |
Tue 16 Jun 2026 @ 05:00 PM (CEST)
Under the Hood: Check Point SASE | Internet Access Optimization & Performance TuningThu 18 Jun 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: Check Point WAF - The Next Generation of AI powered protectionTue 23 Jun 2026 @ 05:00 PM (CEST)
Under the Hood: Check Point Cloud Firewall | Securing all of your clouds: Art of the possibleTue 16 Jun 2026 @ 05:00 PM (CEST)
Under the Hood: Check Point SASE | Internet Access Optimization & Performance TuningThu 18 Jun 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: Check Point WAF - The Next Generation of AI powered protectionTue 23 Jun 2026 @ 05:00 PM (CEST)
Under the Hood: Check Point Cloud Firewall | Securing all of your clouds: Art of the possibleThu 25 Jun 2026 @ 10:00 AM (PDT)
AI Security Masters E10: READY OR NOT: Securing the AI Enterprise 2/5 - AI Red TeamingAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY