Looking at your screenshot, the client shows Disconnected | Invalid date, version 88.62.2010. That's actually the key clue here: if the endpoint is disconnected from the Management/Infinity Portal, it never received the current uninstall password policy, so neither "secret" nor the password you have on record will match. You're fighting the wrong problem by trying passwords. You need to get it reconnected first (or use the local workaround below to reset the password hash).
1. Run the built-in connectivity checker
In the install folder there's a diagnostic tool:
C:\Program Files (x86)\CheckPoint\Endpoint Security\Endpoint Common\bin\CheckConnectivity.exe
Run it and check the output line by line. Example of a healthy-ish run:
### Testing connectivity to Checkpoint Endpoint Security online services
### Checking network connection. Connected
Testing connection to Threat Emulation cloud................................. OK
Testing connection to Threat Emulation cloud 2................................ OK
Testing connection to Data Collection service.................................. OK
Testing connection to Microsoft Store........................................... OK
Testing connection to Clients2.googleusercontent.com............................ OK
Testing connection to Clients2.google.com....................................... OK
Testing connection to Akamaitechnologies a88.................................... OK
Testing connection to Akamaitechnologies a95.................................... Fail
Testing connection to Endpoint-management AmazonAWS............................. OK
Testing connection to Endpoint-managment Platform................................ OK
Testing connection to E2 Signatures.............................................. OK
Testing connection to E2 Live protection......................................... Fail
Testing connection to Googleapis EU/US/UK........................................ OK
Testing connection to Cloudfunctions.net......................................... OK
Testing connection to Cloudinfra-gw.portal.checkpoint.com........................ OK
Testing connection to Cloudinfra-gw-us.portal.checkpoint.com..................... OK
Testing connection to Cloudinfra-gw.ap.portal.checkpoint.com..................... OK
Testing connection to Endpoint-cdn.epmgmt.checkpoint.com......................... OK
A couple of individual "Fail" lines aren't automatically fatal, most of the list should read OK. Read what's failing specifically:
- Akamaitechnologies a95 failing alone is usually low severity (CDN edge node reachability, can be transient/regional). Not the prime suspect.
- E2 Live Protection failing is more relevant. That check is a DNS TXT record lookup against SophosXL's reputation cloud (
*.sophosxl.net). The garbled looking hostname is normal/expected for that lookup, it's not malformed. If this specific query fails while everything else resolves fine, look at whatever is doing DNS filtering upstream (local firewall/UTM, DNS security service, or ISP level filtering); some of these block or rewrite unusual TXT style DNS queries or overly long subdomains. Try nslookup -type=TXT <thatdomain> and also test after temporarily pointing DNS at 8.8.8.8/1.1.1.1 to compare.
2. Check the system date/time, this is likely your root cause
Your screenshot literally shows "Invalid date" next to Disconnected. If the PC's clock or timezone is wrong (dead BIOS/CMOS battery is a very common cause on older machines), the TLS certificate validation on the persistent management connection will fail even though basic HTTPS reachability (what CheckConnectivity mostly measures) still comes back OK. That mismatch, "everything OK but still Disconnected", is a classic symptom of a clock skew problem.
- Check Date/Time and Time Zone in Windows settings
- Confirm NTP sync is actually working (
w32tm /query /status)
- Fix the clock, restart the Check Point Endpoint services (or reboot), then re-run CheckConnectivity.exe and check if the client shows Connected with a valid date afterward
3. Also worth checking
- License status in the portal. If the license/subscription has expired, the client can be blocked from communicating properly, which would produce the same "connects to some services, not others" pattern.
- Local firewall / third party AV / network security appliance. Confirm nothing on the box or on the perimeter is blocking Check Point's cloud endpoints specifically.
Once connectivity is restored and the client shows a proper "Connected" status with a valid last contact date, it should sync down the correct current uninstall password from the policy, and the uninstall should go through normally.
4. If reconnecting isn't practical, local password reset workaround
If you just need it off this machine and don't need to keep it managed, you can reset the uninstall password locally instead of chasing connectivity:
- Boot Windows into Safe Mode without networking.
- Open Windows Services and disable every Check Point related service.
Note: some services may show "Access denied", those can be skipped.
- Open Registry Editor and go to:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\CheckPoint\Endpoint Security
Delete these two keys:
UninstPwdHashDA and UninstPwdSaltDA
- Reboot the machine normally.
- Remove Check Point Endpoint from Control Panel. When prompted for the password, enter
secret (no quotes).
Come back with the CheckConnectivity.exe output and whether the date/time was off, happy to help narrow it down further before you resort to the registry method.
