R82 + Windows Server 2025 – LDAPS Connection Fails

[ghosty]

Hi,

In my lab environment I'm running:

• Check Point R82 – Build 151

• Distributed deployment

• Windows Server 2025

• LDAPS (port 636)

• AD CS Enterprise Root CA

Working:

• Port 636 reachable

• I can browse AD structure in SmartConsole

Failing:

• Connection attempts fails with:
  “Gateway could not connect to… Credentials are valid, but LDAP communication with the server failed.

I have done the solution steps in sk164834.

On both SMS and Gateway:

cpopenssl s_client -connect DC_FQDN:636

Returns:

Verify return code: 21 (unable to verify the first certificate)

Question:

Is anyone able to replicate this behavior on R82 with Windows Server 2025?
Any tips on additional troubleshooting steps would be appreciated.

Thanks.

[ghosty]

Still didn't work after reboot 😞

[the_rock]

Sorry mate, I got nothing else then 😞

[the_rock]

Hey Casper,

Mind sending the output of services.msc from your lab windows? I want to compare it to mine, see if its different.

[the_rock]

Will compare later and update you.

[the_rock]

I did some search online and below is what it came up with that could potentially block this communication. On my end, ONLY windows defender firewall is disabled. You may want to give that a go.

 

[_Val_]

From Ai Copilot:

R82 + Windows Server 2025 – LDAPS Connection Fails: Troubleshooting Guide

You are experiencing LDAPS (port 636) connection failures between Check Point R82 (Build 151) and Windows Server 2025, with the error:

"Gateway could not connect to… Credentials are valid, but LDAP communication with the server failed." andcpopenssl s_client -connect DC_FQDN:636returns:
Verify return code: 21 (unable to verify the first certificate)

You have already followed sk164834. Here are additional troubleshooting steps and explanations based on Check Point documentation and best practices.

---

1. Understanding the Error

• Verify return code: 21 (unable to verify the first certificate)
  This means the Check Point server cannot validate the certificate chain presented by the Domain Controller (DC). Most often, this is because the DC's certificate chain (including the Root CA and any intermediate CAs) is not trusted by the Check Point server.

---

2. Required Steps for LDAPS Trust

A. Export the DC's Certificate Chain

1. On the Domain Controller:

   • Run:

     certutil -store -v MY
     

   • Identify the certificate used for LDAPS (look for the one with the DC's FQDN as the CN).
   • Export the full certificate chain (including the Root CA and any intermediates).

2. Alternatively, from the Check Point server:

   • Run:

     cpopenssl s_client -connect <DC_FQDN>:636
     

   • Copy the certificate text between-----BEGIN CERTIFICATE-----and-----END CERTIFICATE-----to a file (e.g.,dc_cert.cer).

B. Import Certificates to Check Point

• On both the Security Management Server (SMS) and Gateway:
  1. Copy the exported certificate files to the server.
  2. Import the Root CA and any intermediate CA certificates into the system's trusted store.
     • For Gaia, use the WebUI:
       Home > System Management > Certificates > Trusted CA
     • Or, for CLI:

       cpca_client lscert -kind ICA
       # Import using cpca_client or system tools as appropriate
       

  3. Restart Check Point services if required.

C. Verify Certificate Trust

• After importing, re-run:

  cpopenssl s_client -connect <DC_FQDN>:636
  

  • The output should now show:

    Verify return code: 0 (ok)
    

---

3. Additional Troubleshooting

A. Check for Stronger Authentication Requirements

• If you see errors about "LDAP_STRONG_AUTH_REQUIRED" or similar, check the DC's security policy:
  • On the DC, runsecpol.msc
  • Go to:
    Security Settings > Local Policies > Security Options > Domain controller: LDAP server signing requirements
  • Set to None (for testing) or ensure your Check Point configuration supports signing.

B. Confirm LDAPS Port and SSL Settings

• Ensure the correct port (636) is used and SSL is enabled in the LDAP Account Unit or Directory Scanner settings.

C. Policy Installation

• After making changes, always install policy from SmartConsole to apply new settings.

D. Certificate Fingerprint

• In SmartConsole, when configuring the LDAP Account Unit, use the "Fetch" button on the Encryption tab to retrieve and trust the DC's certificate fingerprint.

---

4. References

• sk84620: How to configure Endpoint Security Server to connect to Domain Controller (DC) via LDAPS
• sk109756: How to verify LDAP server Certificate Fingerprint obtained from the Domain Controller
• sk148312: Authentication randomly fails when using Secure LDAP
• sk104785: "Binding to LDAP server: Failed to check ssl" error

---

Summary Table

Step	Action
Export Certificates	From DC, export full chain (Root, Intermediate, DC cert)
Import to Check Point	Add to trusted CA store on SMS and Gateway
Verify	Usecpopenssl s_client -connect <DC_FQDN>:636and check forVerify return code: 0
Policy	Install policy after changes
Security Policy	Check "LDAP server signing requirements" on DC

---

Final Notes

• This issue is not unique to Windows Server 2025; it is a common trust chain problem with LDAPS.
• If you have followed all steps and still see issues, double-check that the full certificate chain is imported and trusted.
• If you are using a lab CA, ensure the Root CA is not expired or revoked.

If you need step-by-step commands for importing certificates on Gaia, let me know your exact environment (SMS, Gateway, or both) and I can provide tailored instructions.

BE AWARE

Important - To prevent negative impact on your production environment, double-check the provided information in the Administration Guide for the involved product.

Learn more:

1. R82 Harmony Endpoint Server Administration Guide - DirectoryScanner
2. R82 VSX Administration Guide - Troubleshooting-General-Steps
3. sk84620 - How to configure Endpoint Security Server to connect to Domain Controller (DC) via LDAPS

[ghosty]

I decided to use IDC instead. It works great.