Everybody who has worked with Check Point and an LDAP account unit with enabled SSL encryption probably knows the problem with changing fingerprints. Since I have seen many customers struggling with that I have developed a little script which helps with that. But let’s start at the beginning.

Some background

With Check Point you can configure an LDAP account unit to use LDAP as an external authentication mechanism. You can use that account unit in multiple places. The main purpose is to authenticate your users on various occasions like VPN, captive portal and more. An account unit contains one or more LDAP servers and some settings related to them. You can also enable SSL encryption (LDAPs) on the LDAP servers to use an encrypted connection to the servers.

So what’s the issue?

If you want to use an encrypted LDAP connection (of course you do!) you cannot just verify the certificate of the LDAP server. The gateway which connects to the LDAP server just calculates the MD5 fingerprint of the certificate. It does not actually care about the certificate itself. What I would expect of a security solution is this:

  • Fetch the certificate
  • Verify that it is signed by a trusted CA or furthermore by a trusted CA I have specified on the account unit
  • Verify that the certificate is actually for the system I am connecting to (common name)
  • Make sure the certificate is not revoked by checking the CRL of the CA

What Check Point is giving us is that we can fetch the fingerprint of the certificate when configuring the account unit. It is not only not that secure since it is using the MD5 hash it is also a very bad idea since it will break the LDAP connection as soon as the server changes its certificate.

Since most customers are using their active directory as LDAP servers with a Windows CA, the certificate on the domain controllers are changing quite frequently. At least once a year depending on your certificate templates. As soon as this happens, it breaks down the LDAP connection from your Check Point gateway leading to authentication issues for your users.

The pain with Check Point and LDAPs - facepalm

Most customers are using multiple LDAP servers in the account unit and the chance that all of them change their certificate at once is quite small, so you might be lucky enough to recognise the change and adapt the configuration before everything breaks down.

So that leaves us three options at the end:

  1. Use an unencrypted LDAP connection which you don’t want to do, since you will be transferring your users password in plain text through the network.
  2. Enable encryption but don’t specify any fingerprint. Yes! You can really do that which tells the gateway to just accept any fingerprint. Is it a good idea? No absolutely not, please don’t do that.
  3. Specify the fingerprint and monitor the LDAP servers so you can detect when they change their certificate.

The medicine

Since I got tired of that stupid behaviour I have created a little script which monitors the fingerprint of the LDAP servers. My customers are running it at least once a day to check the fingerprint. When it changes, the script sends an e-mail to warn about this.

You can find the script on Gitlab: Tobias / checkpoint-ldaps-fingerprint-monitoring · GitLab

To implement it on your management server or gateway do the following:

  1. Copy the script on the server to “/home/admin/scripts/checkpoint-ldaps-fingerprint-monitoring.sh” or any other location you prefer.
  2. Change the variables on top of the script.
  3. Implement a cron job to run the script at least once a day.
# do this in clish
add cron job ldaps_monitoring command /home/admin/scripts/checkpoint-ldaps-fingerprint-monitoring.sh recurrence daily time 07:30
save config

4. Make sure to test the script by inserting an invalid fingerprint and running the script. If everything works, you should get the            e-mail.

Warning: The script does currently not do the following:

  • Verify the new fingerprint against a defined CA. So make sure you check the new certificate before you trust it.
  • Change the fingerprint automatically, you still need to do some stuff yourself :-). Reason for that is that I did not find an API to automate that. And before I would do that, I need to resolve the first point.

I might implement that stuff in the future. So make sure you follow the Gitlab repository.