LDAP connection issues with TLS (1.3)

[domibarton]

Hello

We had some issue with the LDAP connection for the password change.
After some reverse-engineering we could figure out, that PHP, resp. the ldap_bind() function didn't accept the SSL certificate:

TLS: peer cert untrusted or revoked (0x42)

This is due to the missing hint / link to the certificate authorities.
The ca-certificates (apt) package is installed, but the LDAP config is missing.

We could fix it by adding the following config:

cat /etc/ldap/ldap.conf 
TLS_CACERT /etc/ssl/certs/ca-certificates.crt

This will define the CA certificate store to the one provided by the ca-certificates Debian package.
Alternatively libldap-common can be installed, as it will provide the default /etc/ldap/ldap.conf as well.

[pabzm]

@domibarton Thank you for the report!

Is your issue really related to the container-images? It sounds like it could also happen with the application on any host, is that correct?

[domibarton]

Yeah it could actually happen on "any" host where the libldap-common package is missing.
However, on the host the user can decide himself if he wants to install that apt package.

For the Docker image, I expected that LDAP works out of the box (with official CA's), since LDAP support is built-in.
Thus I'd install that package in the Docker image, or at least configure the LDAP client.

It "seems wrongs" that if you say Roundcube supports LDAP, but if you want that support you need to build the image yourself – esp. since the "fix" is quite simple, and doesn't involve a huge dependency tree or alike.

[pabzm]

Thank you for the explanation!

We actually do install libldap-common already, but remove it after building the PHP extension, so it wouldn't be a big deal to keep that package in the image.

But installing it apparently doesn't introduce the wanted config option:

% docker run -it --rm docker.io/roundcube/roundcubemail:latest-apache bash -c 'apt-get -qq update; apt-get -qq install -y libldap-common >/dev/null 2>&1; cat /etc/ldap/ldap.conf'
#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE	dc=example,dc=com
#URI	ldap://ldap.example.com ldap://ldap-provider.example.com:666

#SIZELIMIT	12
#TIMELIMIT	15
#DEREF		never

Are there maybe other steps necessary, too?

[domibarton]

Thank you for the explanation!

We actually do install libldap-common already, but remove it after building the PHP extension, so it wouldn't be a big deal to keep that package in the image.

But installing it apparently doesn't introduce the wanted config option:

% docker run -it --rm docker.io/roundcube/roundcubemail:latest-apache bash -c 'apt-get -qq update; apt-get -qq install -y libldap-common >/dev/null 2>&1; cat /etc/ldap/ldap.conf'
#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE	dc=example,dc=com
#URI	ldap://ldap.example.com ldap://ldap-provider.example.com:666

#SIZELIMIT	12
#TIMELIMIT	15
#DEREF		never

Are there maybe other steps necessary, too?

Mhm apparently the TLS_CACERT config option isn't in the default LDAP config :/
Sorry, thought it's in there.

So we've 3 options:

• Don't add it, and expect users to "just know it", resp. let them find this issue?
• Don't add it, but document it somewhere?
• Add it explicitly

[pabzm]

I would prefer to document it, since I'm not sure about possible side-effects in non-TLS setups. But actually I think the plugin's README, and/or maybe the wiki, would be the right place to document that, since those don't mention that requirement, either.

What do you think?

Would you maybe open a pull request in the main repo proposing a documentation change?

[domibarton]

I would prefer to document it, since I'm not sure about possible side-effects in non-TLS setups. But actually I think the plugin's README, and/or maybe the wiki, would be the right place to document that, since those don't mention that requirement, either.

What do you think?

I usually like when the docs are "as close to the code as possible" – in this case, I think the plugin README is a good idea ;)
We could then also do a little reference from the wiki to the plugin docs, in case anyone is checking out the wiki first.

Would you maybe open a pull request in the main repo proposing a documentation change?

Yeah I can do that, no worries :)