- Products
- Learn
- Local User Groups
- Partners
- More
Access Control and Threat Prevention Best Practices
5 November @ 5pm CET / 11am ET
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Overlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Spark Management Portal and More!
Hello,
We are using Algosec to analyze our devices through Lea + CMI on an MDS installation, and everything was working fine until we needed to add a separate CMA + gateways in new domain. In this case, log collection from gateway devices occurs not on a MLM or CMA server, but on a standalone log server that is located in our new domain.
During the log analysis process, Algosec tries to access the standalone server directly via LEA using a previously generated certificate (which was created in the OpsSec application object). Although Algosec can correctly identify the log server, when trying to access it via the LEA API, an error message is displayed: "ERROR: SIC ERROR 301 - SIC Error for lea: Certificate chain is inconsistent". The corresponding errors are not observed if the analysis is run from a gateway whose log server is specified as MLM.
I have consulted this knowledge base article, but on the standalone server, it does not allow any operations with the cpca_client: https://support.checkpoint.com/results/sk/sk181527.
Therefore, my question is: Is it possible to allow access to the standalone log server through LEA using the certificate?
Version Take 84 R81 20
@PhoneBoy @the_rock
Good afternoon
We found out that the problem is on the side of Algosec.
Algosec considers the certificate issued by CMA is root certificate for the Standalone log server and refuses to process the certificate issued by ICA MDS.
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] fwKeyHolder:
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] Root CAs
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] 1: O=MDS..chjwvb
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] O=MDS..chjwvb
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] Certified keys
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] 1: algosec
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] Has Private
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] CN=algosec,O=MDS..chjwvb
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] O=MDS..chjwvb
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] Root: O=MDS..chjwvb
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] fwCert_FixChain_do: didn't find root ca in chain top
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] fwCert_FixChain_do: Can't find the chains' root CA in my token
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] ckpSSL_VerifyCallback: failed to fixed chain
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] SSL e stack
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] 2773:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:902
no because it s not a check point problem as i expected
The command here is relevant for running on management only (i.e. the Internal CA).
I suspect you'll need to regenerate the certificate for the log server in question.
I suggest involving TAC here.
Good afternoon. I don't see any problems with algosec here. For some reason, the log server itself rejects the CMMI certificate, despite the fact that it received it according to global policies. The re-creation of the CPMI certificate did not give any result
I suggest involving TAC, as stated previously: https://help.checkpoint.com
I would also open TAC case. It might be tricky to get this done with standalone, if its even possible.
Andy
Good morning. Thanks for your reply. I am interested in which of the demons is responsible for obtaining a certificate for LEA and CPMI, and if it is CPCA, then the question of its functionality on not MGMT devices (standalone log, MLM)
And the answer is, in fact, cpca.
@PhoneBoy @the_rock
Good afternoon
We found out that the problem is on the side of Algosec.
Algosec considers the certificate issued by CMA is root certificate for the Standalone log server and refuses to process the certificate issued by ICA MDS.
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] fwKeyHolder:
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] Root CAs
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] 1: O=MDS..chjwvb
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] O=MDS..chjwvb
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] Certified keys
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] 1: algosec
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] Has Private
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] CN=algosec,O=MDS..chjwvb
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] O=MDS..chjwvb
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] Root: O=MDS..chjwvb
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] fwCert_FixChain_do: didn't find root ca in chain top
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] fwCert_FixChain_do: Can't find the chains' root CA in my token
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] ckpSSL_VerifyCallback: failed to fixed chain
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] SSL e stack
[ 2773 4147275584]@Algosec[22 Oct 10:32:23] 2773:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:902
Did you end up opening TAC case about it?
Andy
no because it s not a check point problem as i expected
Fair enough
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 24 | |
| 8 | |
| 7 | |
| 6 | |
| 5 | |
| 4 | |
| 4 | |
| 3 | |
| 3 | |
| 2 |
Wed 05 Nov 2025 @ 08:00 AM (IST)
Your First Response: Immediate Actions for Cyber Incident Containment - AMERWed 05 Nov 2025 @ 08:00 AM (IST)
Your First Response: Immediate Actions for Cyber Incident Containment - AMERWed 05 Nov 2025 @ 11:00 AM (EST)
TechTalk: Access Control and Threat Prevention Best PracticesThu 06 Nov 2025 @ 10:00 AM (CET)
CheckMates Live BeLux: Get to Know Veriti – What It Is, What It Does, and Why It MattersTue 11 Nov 2025 @ 10:00 AM (CET)
Your First Response: Immediate Actions for Cyber Incident Containment- EMEAThu 20 Nov 2025 @ 05:00 PM (CET)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - AMERTue 11 Nov 2025 @ 06:00 PM (COT)
San Pedro Sula: Risk Management al Horno: ERM, TEM & Pizza NightAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY