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 ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_NEVER) ..in python programs. We do that in the TLNC, but not for the rest of our LDAP applications. 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: $ ./demoldapvi 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 never.
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. ***
