LDAPS connections from the gateway will be downgraded to the legacy certificate validation.

[SkochilovIgnat]

Hello everyone!

I want to enable LDAPS port 636 for Identity Awareness on my R82 Lab gateway. It currently works with LDAP. However, when fetching server data and the CA fingerprint, I get the following message:

Manual fetch will be needed when the LDAP server certificate is renewed. LDAPS connections from the gateway will be downgraded to the legacy certificate validation. Reason: The LDAP server certificate should contain Authority Information Access extention with URI with http scheme

What should I do to properly configure LDAPS on the R82? Is there a guide for this?

[Chris_Atkinson]

The starting point for configuring the Account Unit is here:

https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Cont... 

[the_rock]

Let me see if I can replicate this in my lab.

[Vincent_Bacher]

This is very interesting, since we are using Identity Awareness intensively.
Your message states: “The LDAP server certificate should contain an Authority Information Access extension with a URI using the HTTP scheme.”

I verified this on our LDAP server using:

openssl s_client -connect <ldapserver>:636 -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -text

On this server, the relevant AIA → CA Issuers entry is indeed missing.

After investigating further, it appears that Check Point uses LDAPS with certificate chain retrieval.
When the LDAP server presents its certificate, Check Point expects the Authority Information Access (AIA) extension to include an HTTP URL where the issuing CA certificate can be downloaded, for example:

        X509v3 extensions:
            Authority Information Access:
                CA Issuers - URI:http://ca.domain.com/ca.crt

If this extension is missing, Check Point shows the warning.

For me, this means that without the AIA extension, Check Point simply falls back on legacy certificate verification without downloading the CA certificate via the extension and then performing the verification. LDAPS still works, but Check Point no longer uses AIA-based chain retrieval and therefore operates in legacy mode.

Can anyone confirm this?

[SkochilovIgnat]

I tried setting up a CA server. In the AIA extension settings, I left only the HTTP link to the root certificate in the list and checked the box to include this option to AIA extension of issued certificates.

After running the `cpopenssl s_client -connect 10.10.34.41:636 -showcerts </dev/null 2>/dev/null | cpopenssl x509 -noout -text` command, I saw that the certificate information was now displayed as follows:
Authority Information Access:
CA Issuers - URI:http://SRV121.chkplab.local/CertEnroll/SRV121.chkplab.local_chkplab-SRV121-CA(1).crt

I checked this link and the certificate is available, but I still get this warning in the Smart Console.
I will continue to search for a solution to the problem, if I succeed, I will write about it here.

[SkochilovIgnat · Accepted solution]

I found the place where I made a mistake.

I forgot to specify the DNS server, so when fetching the certificate, the CheckPoint couldn't correctly interpret the link because of the domain name in it. When I specified the correct DNS server on the gateway and SMS, everything worked and the warning didn't occur.

However, I think the settings I described above are also necessary.

[Vincent_Bacher]

Did it now work with or without the AIA info without warning message?

[SkochilovIgnat]

Currently, it works with AIA info, when I disable the option to include http URI in AIA extension, warning returns. So this information is needed.

Now, when I press the fetch button, the information is pulled and the CA field is automatically filled, no warning.

[George_Sas]

I went from 81.10 to R82 (forced by a new 2570 gateway that came with R82) and in 81.10 all worked fine without AIA in the certificates.
Seems R82 forces many things and changed many things in Smart Console and Smart Dashboard.

Before R82 I could fetch the thumbprints just fine without any HTTP in my CA URI. Anyway I guess is a good step forward as Windows Server 2025 seems to require this. On Windows 2022 on DC's at the moment.

[the_rock]

Very good to know. Appreciate you letting us know all those details @George_Sas 

[the_rock]

Great job!

[Vincent_Bacher]

Hey, I helped out just a little bit too. 😄

[the_rock]

Of course you did, Vin, you ALWAYS do! 🙌

[George_Sas]

I am facing same problem after upgrade to R82 but my Authority Information Access has only LDAP URI:

Authority Information Access:
CA Issuers - URI:ldap:///CN=xxxxxx,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=xxxxxx,DC=com?cACertificate?base?objectClass=certificationAuthority

So not sure how I can fetch the fingerprint or at least get it manually to input into the Server field.

[George_Sas · Accepted solution]

Solved.
I had to add to HTTP AIA my CA and re issue the certificates to all DC's , then I could fetch the thumbprints.

On the Root CA server:

Open Certification Authority

Right-click the CA name → Properties

Go to the Extensions tab

From Select extension, choose:
Authority Information Access (AIA)
Click Add… and enter something like:
http://pki.yourdomain.com/CertEnroll/%1_%3%4.crt

Select :
Include in the AIA extension of issued certificates
Include in the online certificate status protocol (OCSP) extension (optional)

[the_rock]

Thanks for letting us know!

[AkosBakos]

Hi George,

I have two questions:

Q1: Is the DER format acceptable, or only PEM format supported?

Q2: In TIER 2  PKI setup, the LDAPs cert is issued by the intermediate CA. 

From Select extension, choose:
Authority Information Access (AIA)
Click Add… and enter something like:
http://pki.yourdomain.com/CertEnroll/%1_%3%4.crt

In this case the .crt (that you mentoned above) must be a the Root CA or can it be the intermediate CA as well?

Akos

[George_Sas]

1. None of them. When you press the fetch certificate it will just fetch it from server and check against the CA specified in the certificate. As it is my internal root CA everything is seamless as long as the CRL URLs are in order.

2. Does not matter which CA issues the certificate as long as the management server can get in touch with it and verify the validity.