ldap_modify: error (80)

[dengshuan]

I got ldap_modify: Other (e.g., implementation specific) error (80) error during startup with godaddy certificate
I start the container by

docker run -d -v $HOME/certs:/container/service/slapd/assets/certs \
    -h ldap.mycompany.com \
    --name=ldap \
    -e LDAP_TLS_CRT_FILENAME=425ddb461b040d25.crt \
    -e LDAP_TLS_KEY_FILENAME=mycompany_com.key \
    -e LDAP_TLS_CA_CRT_FILENAME=gd_bundle-g2-g1.crt \
    -e LDAP_ORGANISATION="My Company Inc." \
    -e LDAP_DOMAIN="mycompany.com" \
    osixia/openldap:1.0.9

but it exited with status 80. Here are the logs where it fails:

Use TLS
Files /container/service/slapd/assets/certs/425ddb461b040d25.crt and /container/service/slapd/assets/certs/planetmeican_com.key already exists
ldap_modify: Other (e.g., implementation specific) error (80)
modifying entry "cn=config"

*** /etc/my_init.d/slapd failed with status 80

*** Killing all processes...

At first i tried to use a self-signed certificate generated by openssl, but it seems that this image uses gnu-tls, and they're incompatible, so it doesn't work. After that i used certificate generated by this image, that works.
but when i changed to godaddy certificate, i got this error. I even tried to replace gnutls with openssl in dockerfile and container-start.sh and rebuild the image, but got the same error

[dengshuan]

As debian wiki says debian's openldap is compiled with gnutls, this would have problems with certificate generated by openssl. But it also says Squeeze plays nice with openssl too. It doesn't mention jessie.
I tried to replace gnutls with openssl in Dockerfile and container-start.sh, it does play well with self-signed certificate generated by openssl. But godaddy certificate still get into work. So I wonder there's still problem with openssl certificates

[phlegx]

@dengshuan Getting the same error. Could you solve it by replacing gnutls with openssl or otherwise? If yes, how did you replace it if I may ask? Could you post your configuration?

thanks a lot!

[rhelms]

This happened for me because I had a custom.ldif that attempted to load the memberof module, but it would seem that the memberof and refint modules are already installed by default (at least in 1.1.9).

Set the LDAP_LOG_LEVEL: -1 and look through last bit of output:

source-ldap             | 599119e3 >>> dnNormalize: <cn=module{1}>
source-ldap             | 599119e3 <<< dnNormalize: <cn=module{1}>
source-ldap             | 599119e3 module_load: (memberof) already loaded
source-ldap             | 599119e3 olcModuleLoad: value #0: <olcModuleLoad> handler exited with 1!
source-ldap             | 599119e3 send_ldap_result: conn=1025 op=1 p=3
source-ldap             | 599119e3 send_ldap_result: err=80 matched="" text="<olcModuleLoad> handler exited with 1"
source-ldap             | 599119e3 send_ldap_response: msgid=2 tag=105 err=80

[ehehdada]

I also got this *** /container/run/startup/slapd failed with status 80 problem, the CRT and the KEY files work fine in other containers like nginx:alpine and idef1x/mail-owncloud-docker. The CRT is a bundle including the intermediate CA and the root CA. May this be the problem?

[tushar-sakpal]

@phlegx Did you get it working?
@dengshuan Can you please post your configuration when you replaced gnutls with openssl? Thank you!

[johansmitsnl]

Any news if it is solved? I ran into the same issue.

[joside]

I also have this issue when using a DigiCert Certificate. Can anyone help?

docker run -v /home/ldap-admin/ldap/certificates:/container/service/slapd/assets/certs:rw -h ldap.xxx.de --name openldap -e LDAP_TLS_CRT_FILENAME=xxx.de.crt -e LDAP_TLS_KEY_FILENAME=xxx.de.key -e LDAP_TLS_DH_PARAM_FILENAME=xxx.de.pem -e LDAP_TLS_CA_CRT_FILENAME=xxx.de.ca.crt osixia/openldap --copy-service --loglevel debug

modifying entry "olcDatabase={1}mdb,cn=config"
Add custom bootstrap ldif...
Add TLS config...
Hi! I'm ssl-helper, what button should i press ?
cfssl-helper is launched, everybody on the floor!
Files /container/run/service/slapd/assets/certs/xxx.de.crt and /container/run/service/slapd/assets/certs/xxx.de.key exists, fix files permissions
5d308552 conn=1024 fd=12 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi)
5d308552 conn=1024 op=0 BIND dn="" method=163
5d308552 conn=1024 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
5d308552 conn=1024 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71
5d308552 conn=1024 op=0 RESULT tag=97 err=0 text=
5d308552 conn=1024 op=1 MOD dn="cn=config"
5d308552 conn=1024 op=1 MOD attr=olcTLSCipherSuite olcTLSCACertificateFile olcTLSCertificateFile olcTLSCertificateKeyFile olcTLSDHParamFile olcTLSVerifyClient
5d308552 conn=1024 op=2 UNBIND
ldap_modify: Other (e.g., implementation specific) error (80)
modifying entry "cn=config"
*** /container/run/startup/slapd failed with status 80

*** Run commands before finish...
*** Killing all processes...

[brunowego]

Similar question but with helm chart:

helm install stable/openldap \
  -n openldap \
  --namespace openldap \
  --set env.LDAP_ORGANISATION='Example Inc.' \
  --set env.LDAP_DOMAIN=example.com \
  --set tls.enabled=true \
  --set tls.secret=openldap.tls-secret \
  --set persistence.enabled=true

$ kubectl logs -n openldap openldap-6654664ff5-7rmzr                                                                                                                             18:39:19
*** CONTAINER_LOG_LEVEL = 3 (info)
*** Search service in CONTAINER_SERVICE_DIR = /container/service :
*** link /container/service/:ssl-tools/startup.sh to /container/run/startup/:ssl-tools
*** link /container/service/slapd/startup.sh to /container/run/startup/slapd
*** link /container/service/slapd/process.sh to /container/run/process/slapd/run
*** Set environment for startup files
*** Environment files will be proccessed in this order :
Caution: previously defined variables will not be overriden.
/container/environment/99-default/default.startup.yaml
/container/environment/99-default/default.yaml

To see how this files are processed and environment variables values,
run this container with '--loglevel debug'
*** Running /container/run/startup/:ssl-tools...
*** Running /container/run/startup/slapd...
Start OpenLDAP...
Waiting for OpenLDAP to start...
Add TLS config...
*** /container/run/startup/slapd failed with status 80

*** Killing all processes...

[Alesh]

It seems that somewhere the file names are hardcoded. When I return the default names (ca.crt, server.crt, server.key), I no longer meet this error.

[Jyrno42]

The hard-coded paths reside in https://github.com/osixia/docker-openldap/blob/stable/image/service/slapd/startup.sh#L58

I will submit a PR about this.

[pupper68k]

Just wanted to check in and see if there was a fix for this yet. I am experiencing this issue using certs from acme.sh.

[vidarkongsli]

Just wanted to add that I experienced the exact same error, at the same place during first initialization of the container. The issue I had turned out to be concerning the CA cert. I had a non-self-signed certificate and I a) needed to provide the CA certificate, and b) the cert file needed to contain the entire chain, including intermediate certificates. I added a file with the chain in the PEM format, and then it started to work. I used version 1.3.0 of the image.

[LordGaav]

Using 1.4.0 of this image I had to remove olcTLSCACertificateFile entirely (by replacing the LDIF file and removing the part containing the variable, so it isn't touchde).