LDAPS - where to start from?

[Alan DeKok]

On Sep 14, 2023, at 7:22 AM, Pietro N. via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
> The full libldap debug revealed some unexpected errors and this one led me to the solution (or at least to a workaround):
> ...TLS: peer cert untrusted or revoked (0x42)

  That would be it.

> What I'm guessing is:
> 1- ldapsearch uses the debian certificates store, then it finds our internal CA root Certificate there, and it can trust the LDAP Server Certificate
> 2- libldap does not use the system certificates Store by default (does freeradius let set/send any parameter to overcome this behaviour?).

  libldap uses the ca_file configuration item to find the certificates.  That's why there's a ca_file configuration item.

  The reason FreeRADIUS doesn't use the system certificate store is simple: security.

  An LDAP client can connect to random LDAP servers to do queries.  A RADIUS server should not do that. A RADIUS server 

> The workaround I applied:
>  expliciting, in mods-enabled/ldap, tls section:
>    ca_file = /usr/share/ca-certificates/mozilla/ADCArootCert.crt
> 
> My question:
> Given that the tls section states:
> "# The StartTLS operation is supposed to be used with normal ldap connections instead of using ldaps (port 636) connections",
> BUT I'm using LDAPS, should I fear random, unforeseeable behaviour from freeradius? Hm... rethinking it, if the "behaviour" comes from libldap it's possible that you are not able to know it for sure. 

  636 is for TLS.  389 is for unsecured LDAP connections, OR connections which use STARTTLS.

>>> Checked: "-h" does not exist in ldapsearch 2.5.13
>> 
>>  Well, we didn't write ldapsearch, and they don't notify us when their tools change.
> Of course, please just take my note as a suggestion to improve the documentation.

  We accept patches.  Both the source code and GitHub are public.

  One reason people complaining that the documentation is "bad" is because 99% of people don't submit updates to the documentation.  Which makes me not inclined to worry about suggestion on how to improve the docs.

  Alan DeKok.