On Sat, 20 Jul 2019 at 14:42, Ondřej Kuzník <ondra@mistotebe.net> wrote:
On Sat, Jul 20, 2019 at 09:25:17AM +0300, Nikos Voutsinas wrote:
> Hi all,
>
> In the view of the new openldap release, I ran some tests by using the
> current snapshot of the OPENLDAP_REL_ENG_2_4_48 tree and based on my
> findings It seems that this build breaks the back_ldap backend when it is
> used with a remote ldaps:/// server.
>
> In particular, the following snippet of proxy bind configuration, which
> works on the same system, with the same remote ldaps:/// server /
> certificate and the 2.4.47 release, fails with the engineering release of
> 2.4.48. The testing environment was a Debian (Stable/Buster) and Openldap
> was compiled with the Debian's gnu TLS libs. Based on my previous
> experience I would have bet that this is a GNU TLS issue, however this
> seems to be a different case considering that the error happens only with
> the switch from the 2.4.47 to 2.4.48. Could this be another side effect of
> the related to ITS#8427 fixes?
>
> dn: olcDatabase={3}ldap,cn=config
> changetype: add
> objectClass: olcDatabaseConfig
> objectClass: olcLDAPConfig
> olcDatabase: {3}ldap
> olcAccess: to * by * manage
> olcSuffix: cn=authn
> olcRootDN: cn=admin,cn=authn
> olcRootPW: {SSHA}<REMOVED>
> olcDbURI: ldaps://remote-authn.acme.foo:636
>
> The debug output shows the following:
>
> TLS: peer cert untrusted or revoked (0x42)
> TLS: can't connect: (unknown error code).

Hi Nikos,
where/how do you set the CA certificates that slapd should trust?

Hi Ondřej,

I am using the ldap.conf TLS params to provide the path to CAs. That’s the default way for Debian. It works with 2.4.47, it also works for the 2.4.48 openldap client utils) as I mentioned  earlier.

btw I just checked a similar setup on Solaris with OpenSSL (it was easier for me) and yeap ..... it works also there.