- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs 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 | |
16 | |
4 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 | |
2 |
Tue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Thu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY