When I want to validate a Tls mutual autentication with ldapsearch -H ldaps://…, I have an « peer did not return certificate » error message. However, my /etc/openldap/ldap.conf (with r options) is configured with TLS options (certificate, CA, key, tls_verifyclient=demand,…). I have no .ldaprc, LDAPRC, LDAPCONF environnement variable. When I used Ldapsearch -H ldaps://… with options like -o cert -o key -o cafile is Ok. I don’t understand why my ldap.conf is not read.

How do I configure my server for TLS mutual authentication to perform a search via ldapsearch ?

I just want to perform a ldapsearch search with TLS mutual authentication. My backend require mutual authentication because the parameter TLS_REQCERT is demanded. On my client server, i configured my LDAP.conf with his TLS parameters. An OpenSSL test is ok when I check and give all the certificate parameters in command line. But, with my search with ldapsearch, i notice an error « peer did not return certificate » with LDAP.conf configured.

Hi, This is a client server connection. Why I can’t use the file LDAP.conf Regards

Hi Eric

You need to be very careful with this. I ran into a similar problem some time ago and did not find an adequate solution.

As it stands, slapd does not check the server name on a client certificate, or client certificate chain. It only exposes the name to the access control rules. slapd will accept a connection from a client with ANY certificate signed by ANY CA in it's list. As such, the safest way to operate is to have a single dedicated  CA, probably slapo-autoca, that exclusively signs certificates for valid clients, and use the access control rules to limit what the client can see.

If you want something more generic than autoca, like client certificates signed by public CA's, I would HIGHLY recommend putting a proxy in front of slapd and using the proxy (I used haproxy) to validate certificates. Yes this is ugly and cumbersome, but I believe (controversially) it is necessary.

I did start work on a plugin to better handle this but ran out of time. It won't be happening now. In any case, SOME modification to the slapd core would be needed to be able to drop connections from clients that fail certificate validation. At the time, there was ferocious resistance to any suggestion of changing the core, so I wasn't terribly motivated.

As to WHY the certificates are user-only configuration options, I never found an explanation, but always assumed it was so unprivileged system users could not assume the identity of any system daemons or root. This COULD have been implemented in other ways but it is what it is, and not such a big deal.

Regards

Sean.

On 28/12/2024 3:18 am, Quanah Gibson-Mount wrote:

--On Friday, December 27, 2024 2:17 PM +0000 Eric M em.job35@gmail.com wrote:

...

I just want to perform a ldapsearch search with TLS mutual authentication. My backend require mutual authentication because the parameter TLS_REQCERT is demanded. On my client server, i configured my LDAP.conf with his TLS parameters. An OpenSSL test is ok when I check and give all the certificate parameters in command line. But, with my search with ldapsearch, i notice an error « peer did not return certificate » with LDAP.conf configured.

Hi Eric,

You have two options:

a) Use a user specific .ldaprc file to set user specific TLS options

or

b) Use the -o command line switch for the client binaries as documented in the man page.  Example also exists in test067-tls in the test suite.

Regards, Quanah

On Fri, Jan 10, 2025 at 03:00:07PM +1100, Sean Gallagher wrote:

As it stands, slapd does not check the server name on a client certificate, or client certificate chain. It only exposes the name to the access control rules. slapd will accept a connection from a client with ANY certificate signed by ANY CA in it's list. As such, the safest way to operate is to have a single dedicated  CA, probably slapo-autoca, that exclusively signs certificates for valid clients, and use the access control rules to limit what the client can see.

Hi Sean, there is something you omitted since it's obvious to you, but for the sake of clarity I feel I should make it clear for others' sake: with slapd you always configure a different set of CAs for the client (trusted to issue certificates of the servers you connect to) and the server side of the TLS auth (trusted to issue certificates of clients that connect to you).

Any certificates issued by a CA thus trusted will be accepted unless found to be revoked, you are spot on with the rest.

As to WHY the certificates are user-only configuration options, I never found an explanation, but always assumed it was so unprivileged system users could not assume the identity of any system daemons or root. This COULD have been implemented in other ways but it is what it is, and not such a big deal.

Yes, these are considered credentials, you generally do not trust system-wide configuration to store your credentials and as such, these options are ignored.

Regards,

Windl, Ulrich wrote:

Hi!

AFAIK ldapsearch does not use ldap.conf

(and it seems you cannot specify certificates to authenticate as client using ldapsearch).

Wrong. Re-read the ldap.conf(5) manpage. You must use an ldaprc file, not ldap.conf.

Maybe you need to write a tool (or extend ldapsearch to accept additional options for certificates)

Kind regards, Ulrich

...

-----Original Message----- From: Eric M em.job35@gmail.com Sent: Friday, December 27, 2024 3:17 PM To: openldap-technical@openldap.org Subject: [EXT] Re: LDAP Tools don't use LDAP.conf

I just want to perform a ldapsearch search with TLS mutual authentication. My backend require mutual authentication because the parameter TLS_REQCERT is demanded. On my client server, i configured my LDAP.conf with his TLS parameters. An OpenSSL test is ok when I check and give all the certificate parameters in command line. But, with my search with ldapsearch, i notice an error « peer did not return certificate » with LDAP.conf configured.

-----Original Message----- From: Quanah Gibson-Mount quanah@fast-mail.org Sent: Friday, December 20, 2024 7:39 PM To: Eric M em.job35@gmail.com; openldap-technical@openldap.org Subject: [EXT] Re: LDAP Tools don't use LDAP.conf

--On Thursday, December 19, 2024 9:23 PM +0000 Eric M em.job35@gmail.com wrote:

...

How do I configure my server for TLS mutual authentication to perform a search via ldapsearch ?

Can you give better background on what you want to do? Generally it's *not* recommended to use the ldap* tools inside of scripts, for example. I usually use python-ldap as an alternative in that case.

If the tools are not fit to be used in scripts, those tools should be fixed IMHO. The philosophy of UNIX was that any command can be used in a script...

Ulrich

What are the solutions? Client/server or server/server exchanges use their own certificate to enable the TLS connection. LDAP.conf would provide this information but it is not used.

--On Monday, January 6, 2025 6:20 PM +0000 Eric M em.job35@gmail.com wrote:

the ldap.conf(5) manpage specifies :

The ldap.conf configuration file is used to set system-wide defaults to be applied when running ldap clients.

   Users  may create an optional configuration file, ldaprc or

.ldaprc, in their home directory which will be used to override the system-wide defaults file. The file ldaprc in the current working directory is also used.

I've already quoted this to you previously, but you've left it out here, so I'll quote it again:

" Some options are user-only. Such options are ignored if present in the ldap.conf (or file specified by LDAPCONF)."

You've been told multiple different ways to configure client cert auth, you've failed to demonstrate you've paid attention to any of it, repeatedly.

You've generally failed to specify how your server<->server TLS client auth would be occurring. For example, with syncrepl, the syncrepl configuration EXPLICITLY has the bits for configuring cert auth. Same for things like back-ldap and back-meta.

For client<->server TLS auth, it depends on what the client is. For the LDAP client tools (such as ldapsearch), you've been repeatedly told all the different options you have at your disposal. Again, with ZERO indication from you that you've followed any of the options.

--Quanah

On Jan 7, 2025, at 4:37 AM, Eric M em.job35@gmail.com wrote:

I do not completely agree with your answer. What I want to achieve is a client server connection with ldapsearch with mutual TLS auhentification.

``` # Begin test: env LDAPTLS_CERT=/etc/ldap/foo1.crt LDAPTLS_KEY=/etc/ldap/foo1.pem LDAPTLS_CACERT=/etc/ldap/ca.crt ldapsearch -Y EXTERNAL -H ldap://hostname -b dc=example,dc=com '(objectclass=*)' -ZZ ``` — Shawn

These are two servers, one of which is considered a client with the ldap tools (ldapsearch) installed. As indicated in my answers, this works when using an ldaprc file in the $CWD or when specifying the TLS options of the client server with -O options but I can't understand why the information from the LDAP.conf file is not taken into account in this case. My server is a client. You specify that the certificate information in the LDAP.conf file is user-only options. Yes, this is specified in the ldap.conf manpage. This doesn't simplify the processing.