- Products
- Learn
- Local User Groups
- Partners
- More
The Great Exposure Reset
24 February 2026 @ 5pm CET / 11am EST
CheckMates Fest 2026
Watch Now!AI Security Masters
Hacking with AI: The Dark Side of Innovation
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 |
|---|---|
| 54 | |
| 41 | |
| 15 | |
| 14 | |
| 12 | |
| 11 | |
| 11 | |
| 10 | |
| 10 | |
| 8 |
Thu 19 Feb 2026 @ 03:00 PM (EST)
Americas Deep Dive: Check Point Management API Best PracticesTue 24 Feb 2026 @ 11:00 AM (EST)
Under The Hood: CloudGuard Network Security for Azure Virtual WANThu 19 Feb 2026 @ 03:00 PM (EST)
Americas Deep Dive: Check Point Management API Best PracticesTue 24 Feb 2026 @ 11:00 AM (EST)
Under The Hood: CloudGuard Network Security for Azure Virtual WANAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY