LDAP and TLS client authentication

I would like to share here some words about something, that bothered me for around 3 hours until I solved it. And something I have to admit shamefully, that I should've known based on my experience and studies. But we tend to forget stuff, which we don't use regularly and we forget it until the moment, when we need it the most.

In one of my projects I decided to support several independant systems with a centralized user management solution. Of course, in such cases a good choice is always OpenLDAP. Even better, it has some pretty good containers in the Docker Hub. I chose to use osixia/openldap.

It worked immediately like a charm and I was pretty happy. Then I needed to reconfigure the first system, whish had to use it - GitLab CE. GitLab CE in my scenario is also running as a container - gitlab/gitlab-ce - so in this case the communication is done through the net module of K8s. The configuration of GitLab CE for LDAP is pretty straight-forward and well documented in their documentation.

I chose to use the simple TLS authentication method (which is actually not recommended). It works on a separate port - 636. In comparison to the Start TLS method, the communication on the LDAPS port is completely over SSL, where the Start TLS on port 389 starts as plain text and "moves" to TLS over the communication process. Furthermore, based on the server and client configuration, it may stay to plain text.

Servers started ... And then my configuration didn't work ...

As soon as I started logging in as some of the LDAP users, I got error messages from GitLab, that the authentication was unsuccessful, because of a SSL error. The SSL error mentioned, that

SSL_connect SYSCALL returned=5 errno=0 state=SSLv3/TLS write finished

Well that's bad. It is bad, because it is an SSL error. And SSL errors are hard to clarify (except you know what happened). And because they mean something is going wrong under the hood.

After some searching, a lot of openssl commands send over the terminal and a lot of experimenting with ldapsearch I narrowed down the problem. The right thing to do with such a problem is to manually simulate the client system - e.g. GitLab. I opened a remote connection to LDAP and started experimenting with ldapsearch. Immediately I found out, that I was unable to contact the LDAP server, when I am not on the localhost. And by adding "-d -1" to the command line I got verbose output from the ldapsearch command.

This showed me, that the client (ldapsearch) receives the server certificate, but doesn't send its own certificate - probably because I've configured none. But after the client didn't send any certificate the server just dropped the connection.

Then I refreshed my TLS theory and remembered, that there is this possibility, that the server forces the client to authenticate itself, otherwise it drops the connection.

BINGO!

The parameter, that we were searching for in the OpenLDAP server configuration is called

olcTLSVerifyClient

and is typically found in the file

cn\=config.ldif

And it should be actually changed using the command line tool ldapmodify.

After the value was changed from "demand" to "try", there were no more problems connecting to the server over TLS. Neither via GitLab, nor via ldapsearch.