- CheckMates
- :
- Products
- :
- Quantum
- :
- Remote Access VPN
- :
- Re: SNX failing Driver validation
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
SNX failing Driver validation
I've found on my windows 10 22H2 clients that SNX is failing the windows driver validation checks (Secure boot + Driver Signature Enforcement).
checking the setupapi.dev.log file shows the following errors:
Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
Driver package failed signature verification. Error = 0xE0000247
Failed to import driver package into Driver Store. Error = 0xE0000247
When i Check out the SNX security catalog file, it shows that it is not valid, being signed by an old microsoft CA that expired in 2021.
I've attached screenshot of the certs and catalog.
TAC + R&D has indicated that the driver being signed by an expired CA is fine, and that this is likely an issue with a custom CRL on my clients, but I've never applied a custom CRL.
I'm wondering if anyone else has seen this isue on win10 22H2 and later versions of windows. The proposed workaround of disabling secure boot + validation checks will be rejected by the business.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What version of snx is installed?
What gateway version/JHF is relevant here?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
R81.20, JHF 84
SNX version 7.01.0000
Mobile Access Portal Agent 800.007.049
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The SNX version should be a build like 800008302, which you can get with snx -h on the CLI.
The latest appears to be 80008409, which should be applied with the latest R81.20 JHF.
Assuming you're on the most recent release, you're saying it is signed with an old certificate?
Can you send me the relevant SR in a PM?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
the SNX I put above was the 'SLL Network Extender Service' version that gets installed alongside the Mobile Access Portal Agent (actual snx).
SNX build using 'snx -h' is showing 997000069.
this article confirms the latest version for my release is 80008409, and when I do "cat $CVPNDIR/htdocs/SNX/CSHELL/snx_ver.txt" it shows 800008409.
You can also see the old cert signature in the pictures I attached in my original post.
if the windows agent version # is supposed to match, then maybe when my clients are dowloading SNX they are getting an older version.
DM'ing you the SR as well
*edit*
according to https://support.checkpoint.com/results/sk/sk168353 the windows agent version is the latest.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could you please check SNX version that is installed on Windows?
It can be found in "c:\Program Files (x86)\CheckPoint\SSL Network Extender\ver.ini" file.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
800008409
Can anyone confirm what certificate and root CA are signing the SSL extender for them? the security catalog and signer can be found at: C:\Program Files (x86)\CheckPoint\SSL Network Extender\netvna.cat
Click 'View Signature", then click 'View Certificate"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here are from my PC:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you have Secure Boot with driver signature enforcement enabled? Windows should reject SNX if you do based on that.
You can check if Secure boot is enabled in MSINFO under "Secure Boot State"
if off, then driver signature enforcement will also be off.
If Secure Boot State is On, then in an elevated command prompt, run 'bcdedit' and look for "nointegritychecks", if it shows "yes", then driver signature enforcement is off
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Secure Boot is definitely "on".
As for the "nointegritychecks". By default, I don't see its value. When I tried to alter it, I got "The value is protected by Secure Boot policy and cannot be modified or deleted." So, I disabled Secure Boot, explicitly set "nointegritychecks" to "off" and enabled Secure Boot back.
No issues with certificate.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The value won't show if off for nointetegritychecks, it is off by default for security. can you also confirm if you are on windows 10 22h2?
It should be normal for windows to reject a driver signature that comes from an expired CA I think, I don't know why my different windows test clients would be a rare exception in rejecting this instead of allowing it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I check on Win10 22H2 19045.4849
I noticed one interesting thing. The root certificate (Microsoft Root Certificate Authority) has validity period from 10 May 2001 till 10 May 2021.
While on your screenshot it is 9 May 2001 - 9 May 2021.
In my case certificate serial number is 79ad16a14aa0a5ad4c7358f407132e65. Please check with your one.
