Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Tierre_Amaral
Explorer
Jump to solution

Check Point LDAPS connection breaks everytime AD certificate is renewed

Hello everyone,

 

Not sure if someone also has or had this problem but this is the 2nd recurrent year we had been in this situation. We use LDAPS (port 636, LDAP Account UnIt) config to connect to our ADs for Remote Access Usage and IA. Microsoft DCs generate a 1year expiration certificate which Check Point firewall validates using the fingerprint fetch process (Servers > Edit > Encryption > Fetch).

The thing is every year this certificate auto-renews and turns out the old fingerprint becomes invalid and that's where our lives stress out: no one is then able to access Internet through IA rules or connect to the environment through Remote access VPN until we manually fetch the new fingerprint in every LDAP server configured then push policy.

 

I haven't seen any statement from Check Point showing a permanent fix for this (Hotfix or Patch) or any other option that allow us to use LDAPS and auto-fetch the fingerprint or something that not let this happen again.

 

Please help!!!

 

Firewall version is R80.20

 

1 Solution

Accepted Solutions
Royi_Priov
Employee
Employee

Hi @Tierre_Amaral ,

This is not a specific problem to Identity Awareness, but to our authentication I/S.

We had a customer release to change the trust mechanism to be based on PKI, and this way a certificate renewal won't affect the LDAPS query operations.

You are more than welcome to open an RFE for getting this change, until it will be included in our GA versions.

Thanks,
Royi Priov
Group manager, Identity Awareness R&D

View solution in original post

18 Replies
Sigbjorn
Advisor
Advisor

I created a supportcase with TAC on this issue a few years ago. They didn't have a fix, but asked if I could just remove the fingerprint from the account unit. That way Check Point won't try to validate it and will accept any certificate. (This was for R77.30)

This was a good enough workaround for us at the time, since its a closed environment and we don't see any big chances of a mitm or anything.

But it feels like something that should be added to an API if it isn't already.

I'll check the api docuementation for account units on monday, and register an rfe is I cant find a way to fix it.

0 Kudos
Wolfgang
Authority
Authority

@Tierre_Amaral 

this is a very old known limitation. LDAP failing with "SSL finger print does not match" shows the solution mentioned by @Sigbjorn 

A lot of the members here are waiting for a solution, don‘t know if something changed with R81? Did not tried yet but maybe someone here did ?

Wolfgang

0 Kudos
Royi_Priov
Employee
Employee

Hi @Tierre_Amaral ,

This is not a specific problem to Identity Awareness, but to our authentication I/S.

We had a customer release to change the trust mechanism to be based on PKI, and this way a certificate renewal won't affect the LDAPS query operations.

You are more than welcome to open an RFE for getting this change, until it will be included in our GA versions.

Thanks,
Royi Priov
Group manager, Identity Awareness R&D
Martin_Valenta
Advisor

is it going to be fixed in any GA version? it's kind of annoying to re fetch certificates

0 Kudos
Gojira
Collaborator
Collaborator

Just leave the fingerprint field empty 🙂

0 Kudos
piteyyy
Explorer

Is that a joke or a true story?

0 Kudos
Gojira
Collaborator
Collaborator

sorry for the late reply but yeah, that works.

0 Kudos
gm446
Contributor

Hi Royi,

this change is already happened on R81.20?

Best Regards,
Yossi.

Sigbjorn
Advisor
Advisor

I see you'll get the fingerprint in the show-generic-object API, under ldapServers -> ldapSslSettings -> ldapSslFingerprints, so you should be able to update it via set-generic-object as well. (But I haven't had time to figure out the correct syntax for that yet)

To get the current certificate fingerprint you can run this one-liner from the management: cpopenssl s_client -connect 10.10.10.10:636 2>&1 </dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | cpopenssl x509 -noout -md5 -fingerprint

But putting all that aside, the PKI option Royi mentions sounds like the best approach. 🙂 (Hopefully this will be in the default release soon.)

0 Kudos
David_C1
Advisor

Hi @Royi_Priov 

 

Any update on this? All of our IA functionality broke yesterday because of the certificate rotation on our domain controllers.

 

Dave

0 Kudos
the_rock
Legend
Legend

I agree with @Wolfgang . I also saw this before and TAC told me it was a known problem...not sure when CP plans on fixing it though.

0 Kudos
StephS
Explorer

Hi @Royi_Priov,

we have the same problem as @Tierre_Amaral and opened a SR, however Check Point Support told us there is no private fix for this. How are we able to get the fix for this?

Thanks,

Steph

0 Kudos
Arskaz
Contributor

Still unfixed?

0 Kudos
David_C1
Advisor

I can confirm, at least in R81.10 JHFA Take 95, this is still a problem.

Dave

0 Kudos
the_rock
Legend
Legend

Did TAC confirm the same?

Andy

0 Kudos
David_C1
Advisor

TAC didn't need to confirm, my broken IA was all the confirmation I needed (fixed once we re-fetched fingerprints).

Dave

(1)
the_rock
Legend
Legend

Ok, gotcha...so version/jumbo is still the same, you just refetched the fingerprint?

Andy

0 Kudos
David_C1
Advisor

Correct.

Dave

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events