TLS: can't accept: No certificate was found..

[Cinux90]

Hi All,

i'm try to connect via jxeplorer to the docker container where ldapd is running in.
Information which i use to connect to ldap via jxplorer:

Host: localhost
Port: 636
basedn: cn=admin,dc=example,dc=org (also without cn=admin)
benutzer dn: admin
kennwort: admin

Everytime a connection is successfully i face the dialog regarding the not trusted certificate. I can also show the certificat and see at the Subject this: CN=docker-light-baseimage So there should be a certificate exist.

But if i klick on "trust for this session" i face following error at the docker container:

587d1789 conn=1011 fd=16 ACCEPT from IP=192.168.0.1:36882 (IP=0.0.0.0:636)
TLS: can't accept: No certificate was found..
587d1789 conn=1011 fd=16 closed (TLS negotiation failure)

of course without ssl its works well. But its not my intension to work without ssl.

If i check in the container how about certificates i found this:

root@f19c20a6d754:/# find / -iname "*.crt"
/container/service/slapd/assets/certs/ca.crt
/container/service/slapd/assets/certs/ldap.crt

root@f19c20a6d754:/# ls -l /container/service/slapd/assets/certs/
total 20
-rw-rw-r-- 1 openldap openldap 173 Oct 3 12:06 README.md
lrwxrwxrwx 1 openldap openldap 62 Jan 16 19:18 ca.crt -> /container/service/:ssl-tools/assets/default-ca/default-ca.pem
-rw------- 1 openldap openldap 424 Oct 3 12:06 dhparam.pem
-rw-r--r-- 1 openldap openldap 1094 Jan 16 19:18 ldap.crt
-rw------- 1 openldap openldap 288 Jan 16 19:18 ldap.key

i have no idea why its not found any certificate.

I have attach the output if i start the server by running following command:
docker run -it --name ldap -p 389:389 -p 636:636 osixia/openldap:1.1.7
ldap_start.txt

I have no idea how to fix it.
Maybe some of you will help to fix the issue?

greeting,
Cinux90

[charlesmulder]

I have the same problem

[waj6144]

we also have this problem. while playing around with

ldapwhoami -H ldap://ldap.example.com -x -ZZ

i noticed that it was not working from outside the container. there i got the following log lines:

58862bbd conn=1007 fd=16 ACCEPT from IP=10.20.0.50:46270 (IP=0.0.0.0:389)
58862bbd conn=1007 op=0 EXT oid=1.3.6.1.4.1.1466.20037
58862bbd conn=1007 op=0 STARTTLS
58862bbd conn=1007 op=0 RESULT oid= err=0 text=
TLS: can't accept: No certificate was found..
58862bbd conn=1007 fd=16 closed (TLS negotiation failure)

But from inside the openldap containter it seems to work:

58862bb8 conn=1006 fd=16 ACCEPT from IP=127.0.0.1:45578 (IP=0.0.0.0:389)
58862bb8 conn=1006 op=0 EXT oid=1.3.6.1.4.1.1466.20037
58862bb8 conn=1006 op=0 STARTTLS
58862bb8 conn=1006 op=0 RESULT oid= err=0 text=
58862bb8 conn=1006 fd=16 TLS established tls_ssf=128 ssf=128
58862bb8 conn=1006 op=1 BIND dn="" method=128
58862bb8 conn=1006 op=1 RESULT tag=97 err=0 text=
58862bb8 conn=1006 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.3
58862bb8 conn=1006 op=2 WHOAMI
58862bb8 conn=1006 op=2 RESULT oid= err=0 text=
58862bb8 conn=1006 op=3 UNBIND
58862bb8 conn=1006 fd=16 closed

so how can this be solved? is this typical for a problem with the network configuration? or a dns reverse lookup problem? how can i test this?

[betagan]

I ran into the same issue and found a solution.

The problem arises from client verification and can be fixed by adding --env LDAP_TLS_VERIFY_CLIENT=try to your docker run command which according to the docs defaults to 'demand' (https://github.com/osixia/docker-openldap#defaultyaml).
Note that this will disable client authentication - if you ident do use that you might want to check all client certs are signed properly and CA certs are imported to your ldap server trust store.

[osixia]

@betagan thanks for the response indeed LDAP_TLS_VERIFY_CLIENT is set to demand by default so the clients must provide a certificate signed by the ldap trusted ca authorities.

Possible values are : never | allow | try | demand
http://www.openldap.org/doc/admin24/tls.html

It's not really a good idea to use the image default certificate and certificate authority.

[kevdogg]

I have this same issue. The suggested solution of:

--env LDAP_TLS_VERIFY_CLIENT=try

Not sure why it's not verifying the client certificate. Any reason for this?