This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Sign in with your Check Point UserCenter/PartnerMap account to access more great content and get a chance to win some Apple AirPods! If you don't have an account, create one now for free!
Avoiding VPN client fingerprint message when changing certificate
Hello Guys,
I'm in need to change the Certificate which is represented to the Clients for Remote Access.
As far as I Understand, Checkpoint presents the Fingerprint of the Root CA of the VPN Certificate so the client dont have issues when Certificates are exchanged if they come from the same CA.
We have "vpn.corp.com" as CN/DNS. So I digged already into the registry of my clients and there as mentioned a respective fingerprint for my VPN Infrastructure. [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\CheckPoint\accepted_cn\vpn.corp.com] "--Fingerprint--"=" XXXX XXX XXX XXX XXXX XXX XXXX XXXX XXX XXXX XXX XXXX"
1. Question: Can I assign more then one Fingerprint in the Registry ? So we have an entry for our "vpn.corp.com" and there is currently one Fingerprint. Can I enter the second (new one) to and it will work? Is there an SK for this? So it will look like: [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\CheckPoint\accepted_cn\vpn.corp.com] "--Fingerprint--"=" XXXX XXX XXX XXX XXXX XXX XXXX XXXX XXX XXXX XXX XXXX" "--Fingerprint--"=" YYYY YYY YYY YYY YYYY YYY YYYY YYYY YYY YYYY YYY YYYY"
2. Question: If the 1. is not a viable option will I be forced to create a new DNS Entry (for example remote.corp.com) to prepare the registry? And also reflect this in the new certificate ? [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\CheckPoint\accepted_cn\remote.corp.com] "--Fingerprint--"=" YYYY YYY YYY YYY YYYY YYY YYYY YYYY YYY YYYY YYY YYYY"
3. Question: I did not find the SK where it is cleary mentioned which fingerprint of which certificate checkpoint will present its clients. Is there something? Because even the SK above in the text says "From test host with VPN client installed and existing site created, export the following registry key value data:" And this is quite hard in a live environment.
yes as mentioned I found this article, but it is not clear for me if I change the fingerprint if I can enter just a second one in the windows registry. So the client will trust 2 fingerprints, then we migrate the certificate and then we remove the old fingerprint from the client.
I'm in need to let the user trust the old AND the new fingerprint because we cant push the registry key to all clients in the same moment where we replace the cert on the gateway
Safest is to use different site IDs, such as you described in question 2. I would also check in the lab if you can have two fingerprints for a single site. Most probably not, but worth checking.
Also, are you moving CMA to a different IP or just moving the GW to another MGMT? If former, you can keep your fingerprint.
Regarding to question 3: What the CP VPN client is checking here is the RfC#1751 encoded representation of the SHA-1 fingerprint of the root certificate of your VPN GW SSL certificate chain.
@Jacinto_Rodrigu - did you ever get a chance to test this to see if it works.
Also, I know that CP uses the RFC 1751 to create the fingerprint in human text, but do they have a tool to determine the fingerprint without installing/replacing the current certificate on a gateway?
Also, do they plan to make it easier to manage the SSL cert for the MAB? With browsers all enforcing a max validity of 397 days, it means a lot more frequent update of the certificate than in the past, and it's a very manual process with about a dozen steps just to get a proper wildcard cert for a single gateway.
Regarding "Also, I know that CP uses the RFC 1751 to create the fingerprint in human text, but do they have a tool to determine the fingerprint without installing/replacing the current certificate on a gateway?":
--> Maybe, I've never found one. So I used the C code from that RfC, compiled it and used it for converting in both directions. Please take care to use the SHA-1 fingerprint of the root certificate of your VPN GW SSL certificate chain. Not the fingerprint from the actual server certificate or any of the intermediate ones.
$ ./rfc_1751.exe "f9:02:bc:09:9a:9e:58:dc:28:6f:f6:4c:54:dd:71:e0:cf:29:f2:30" Output: WEAN GAM ANT PRY SURF CURL MEW FEUD HALO LAIR SAUL TUBA $ ./rfc_1751.exe "WEAN GAM ANT PRY SURF CURL MEW FEUD HALO LAIR SAUL TUBA" Output: F9:02:BC:09:9A:9E:58:DC:28:6F:F6:4C:54:DD:71:E0
Back in R77 days, I remember it was possible to import the new certificate in SmartDashboard, NOT clicking ok or save, than copy the new fingerprint it shows to you, and than click cancel. Never tried this with R80+ and SmartConsole, maybe it is still working this way.
And as CP is only checking fingerprint of Root CA, there is no need to update trust on clients when you stay with that Root CA while changing server cert every year.
That's what I thought, and I just confirmed that I have the same fingerprint on my two clusters that have the same Root CA. We must have switches Root CAs or the CA must have updated their Root certificate path the last time we renewed as it changed on us and we had to scramble to push out a registry edit to all client so that users didn't get the prompt.
How is everyone handling the need to renew a wildcard certificate every year with the new browser changes introduced over the past year forcing CAs to limit validity to 397 days? Any done any automation or use any 3rd party certificate management tools to help with this process?
Just an update to myself. It's not the fingerprint of the Root CA, it's the CA that issued the certificate. So if you are using a traditional public CA that has a 2 tier hierarchy, it's the intermediate CA fingerprint that it used.
DigiCert Global Root CA
--> GeoTrust RSA CA 2018
---> portal.example.com
So in that example, it's the fingerprint on GeoTrust RSA CA 2018 that is used by the client for verification.
Subject: CN=DigiCert Global Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US Issuer: CN=DigiCert Global Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US Not Valid Before: Thu Nov 9 19:00:00 2006 Local Time Not Valid After: Sun Nov 9 19:00:00 2031 Local Time Serial No.: 083be056904246b1a1756ac95991c74a Public Key: RSA (2048 bits) Signature: RSA with SHA1 Key Usage: digitalSignature keyCertSign cRLSign Basic Constraint: is CA MD5 Fingerprint: 79:E4:A9:84:0D:7D:3A:96:D7:C0:4F:E2:43:4C:89:2E SHA-1 Fingerprints: 1. A8:98:5D:3A:65:E5:E5:C4:B2:D7:D6:6D:40:C6:DD:2F:B1:9C:54:36 2. KURD NEED ARTY RAID BRAE SOOT LOSE MOOR HOVE FIVE CURD HEWN
Subject: CN=GeoTrust RSA CA 2018,OU=www.digicert.com,O=DigiCert Inc,C=US Issuer: CN=DigiCert Global Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US Not Valid Before: Mon Nov 6 07:23:45 2017 Local Time Not Valid After: Sat Nov 6 08:23:45 2027 Local Time Serial No.: 0546fe1823f7e1941da39fce14c46173 Public Key: RSA (2048 bits) Signature: RSA with SHA256 CRL distribution points: http://crl3.digicert.com/DigiCertGlobalRootCA.crl Key Usage: digitalSignature keyCertSign cRLSign Extended Key Usage: serverAuth clientAuth Basic Constraint: is CA 0 levels MD5 Fingerprint: A9:5D:7F:13:A6:4A:5E:BE:00:36:4D:8B:E6:7D:EC:ED SHA-1 Fingerprints: 1. 7C:CC:2A:87:E3:94:9F:20:57:2B:18:48:29:80:50:5F:A9:0C:AC:3B 2. FACT BUSH JOAN OHIO AIDE GREW BETH BLAB ETC BARN AWN ONE
Even worse, the fingerprint that the SNX client shows appears to be the fingerprint of the actual certificate, not the Intermediate or the Root CA as is used by the Endpoint Security client.
I just confirmed this on my SNX install. The fingerprint that the user is prompted to trust (or update every time the SSL certificate is updated) is from the actual SSL Server certificate, not the Intermediate or the Root CA.
Very confusing and hard to tell which fingerprint the user will see. Check Point needs an SK for this sort of information, so that it's clear which certificate fingerprint is used in which situation.
@Tobias_Moritz - Do you have your compiled rfc_1751 executable available anywhere (github/etc)? It's crazy that Check Point does not provide a simple tool for this.
Hello EY, no I don't. And while I wanted to wrote something like: "just compile it yourself", I did a compare of my code in my archive against the orginal one from the RfC and found some things I changed to made it work (modified a helper function to support 16 instead of 8 bits, added one more helper function and the main function to make it a standalone-usable binary). Really forgot that, was a long time ago 😄
Thanks, works perfectly after fixing a few lines the content guard broke.
Line 63: replace "**bleep**" according to RFC1751 Line 114: replace "**bleep**" according to RFC1751 Line 424: change "cc = (y >> & 0xff;" to "cc = (y >> 8 ) & 0xff;"
If Check Point provides such a tool, how would you use it? What do you expect to supply as input and what do you expect to see as output (something else besides fingerprint)?
I dunno how to get this into the Toolbox Scripts board, but I cobbled this together in Python. It's not glorious, so someone is free to clean it as you wish.
#!/usr/bin/python3
import sys, os
import binascii
from Crypto.Util import RFC1751
def main(argv=None):
if argv is None:
argv = sys.argv
if not (len(argv)):
print("Fingerprint hex string missing\n")
print("Usage: {} <string>\n".format(__file__))
print("String may be colon-separated hex (00:01:aa:bb...) or without colons (0001abcd...)\n")
exit(1)
fingerprint_arg=argv[0]
fingerprint_str=fingerprint_arg.replace(':','')
if (len(fingerprint_str) == 40):
fingerprint_hex=fingerprint_str[:32]
elif (len(fingerprint_str) == 32):
fingerprint_hex=fingerprint_str
else:
print("Usage: {} <string>\n".format(__file__))
exit(1)
fingerprint_txt=RFC1751.key_to_english(binascii.unhexlify(fingerprint_hex[:32]))
print("\nASCII fingerprint string:\n")
print(fingerprint_txt)
print("\n")
if __name__ == "__main__":
main(sys.argv[1:])
ASCII fingerprint string:
LAUD RISE KID SOAK OUR TORE MAIN EVA US HOBO SWAG SING
$ script.py 4607BC6AD16849924F612CD2D6EB4358
ASCII fingerprint string:
WOW SPA HIM JOKE FOOL ORGY AVER BUS POP LIAR LUND LEEK
If you are using the Windows certificate details view, the Thumbprint value is 40-bytes, long not 32, so that has to be truncated (which the script does). Feel free to paste the whole 40-byte string as the argument. If you are using openssl x509 -fingerprint, then use the -sha1 argument to get the SHA1 hash (may be default, but a newer openssl may change that some day).
So far, this seems to match certificates and fingerprints that I've tested. No guarantee this is perfect, tho.
By coincidence, I had to do this for a customer today. I'm guessing "things" have changed with the Endpoint VPN client over time, as sk66263 is a bit erroneous. I sent a feedback on the SK article with the changes I observed.
1) The name of the registry key is the name of VPN gateway + the literal text "VPN Certificate" (e.g.: "office-fw VPN Certificate").
2) The fingerprint value is indeed that of the internal_ca (the issuer certificate), not the gateway IPsec VPN certificate (I believe this is different for SAML, however).
If you want to be fancy and clever, using that Python script I attached above, you can get it all in one shot. (obviously use your gateway's IP address)
The SK article is correct, however, on the location of the registry key, so follow that as described. I verified the registry key info on my PC after a manual site configuration and connection, as well.
