Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Cinux90 opened this issue Jan 16, 2017 · 5 comments

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

Cinux90 opened this issue Jan 16, 2017 · 5 comments


Copy link

Cinux90 commented Jan 16, 2017

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= (IP=
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"

root@f19c20a6d754:/# ls -l /container/service/slapd/assets/certs/
total 20
-rw-rw-r-- 1 openldap openldap 173 Oct 3 12:06
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

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


Copy link

I have the same problem

Copy link

waj6144 commented Jan 23, 2017

we also have this problem. while playing around with

ldapwhoami -H ldap:// -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= (IP=
58862bbd conn=1007 op=0 EXT oid=
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= (IP=
58862bb8 conn=1006 op=0 EXT oid=
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=
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?

Copy link

betagan commented Feb 14, 2017

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' (
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.

Copy link

osixia commented Feb 15, 2017

@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

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

Copy link

kevdogg commented Oct 4, 2020

I have this same issue. The suggested solution of:


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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

5 participants