On some distributions, the openldap libraries are configured to demand a valid
TLS certificate whenever a ldaps connection is setup. This can be configured
away by setting TLS_REQCERT never in /etc/openldap/ldap.conf (or
/etc/ldap/ldap.conf, depending on distribution).
There is also the possibility to do that per application by calling
..in python programs. We do that in the TLNC, but not for the rest of our LDAP
Setting this weakens the security, so we should think about it before
implementing it in all scripts. Implementing bug 1535 may help, since that will
actually fetch the certificate that is needed. TLNC still needs to be able to
connect without certificate though, or we'd get a chicken and egg problem.
We should solve this by having a ThinLinc-global configuration parameter.
Decided on devmeeting: Perhaps it's sufficient if it's possible to change this
on a system global basis. In that case, we don't need a TL-specific
configuration parameter, but we could document the issue. Investigate.
Also investigate why demoldapvi on maggie gives:
ldap_bind: Can't contact LDAP server (-1)
additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
..when Peter tries to run it, even though he has a ~/.ldaprc with TLS_REQCERT
As the comments say - investigate and document. Make sure we understand how
settings in /etc/openldap/ldap.conf and /etc/ldap.conf interoperate.
Worth to note is that the certificate downloading in bug bug 1535 should
probably download the certificate to a location where it can be read not only by
nss/pam_ldap, but also by the system's LDAP library, which will allow other
applications, for example our own LDAP reading/setting software, to use secure
ssl as well.
Decided that this means making tl-ldap-certalias configurable.
*** Bug 4101 has been marked as a duplicate of this bug. ***