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).

[cruwe]

Please excuse me, I feel like necro-bumping an old ticket, but as it is still open, I hope not to offend.

First, thank you very much for developing the openldap image and making your effort available to the general public.

I have a very similar issue on k8s with a non-publically singed CA and certificates generated therefrom by hashicorp vault. I observe the same /container/run/startup/slapd failed with status 80 error when adding the TLS configuration with LDAP_TLS="true". Interestingly, securing the endpoint with TLS succeeds when starting the container without ant then manually enabling TLS via ldapmodify -Y EXTERNAL -Q -H ldapi:/// -f /monkeyPatchedTls.ldif.

I resorted to the manual way as a last resort, as bootstrap-seeding did not work either. The situation feels racy, but I have no good idea where to look further. I'd appreciate a hint and am certainly willing to assist in testing / providing further info,

In any case, thanks again for your effort, cheers!

[jboockmann]

I just wanted to add that I have experienced the same error during the first initialization of the container. In my case, I was using a self-signed certificate and forgot to provide the ca.crt file, which must in this case be identical to the cert.crt. I am using version 1.3.0 of the osixia/openldap:1.3.0 docker image.

I have used the following code to generate cert.key, cert.crt, and ca.crt based on my personal csr.conf file:

openssl genrsa 2048 > cert.key
chmod 400 cert.key
openssl req -config csr.conf -new -x509 -days 3650 -key cert.key -out cert.crt
cp cert.crt ca.crt

Hope this helps :)

[cr1cr1]

You also need a DH Parameters file:

• openssl dhparam -out dhparam.pem 4096
• set LDAP_TLS_DH_PARAM_FILENAME=dhparam.pem

[silencej]

For me, check ./certs/dhparams to see if its size is 0. Removing it solves this problem.

[sagayd]

I have had the similar issue. My cert was generated with openssl. I fixed the issue by adding the CA cert also. Note the file names are referenced as here

LDAP_TLS_CA_CRT_FILENAME=ca.crt
LDAP_TLS_CRT_FILENAME=tls.crt
LDAP_TLS_KEY_FILENAME=tls.key

First create a TLS secret for server certificate: kubectl create secret tls tls-openldap --key=server.key --cert=server.crt Next, create a Generic secret for CA certificate: kubectl create secret generic tls-openldap-ca --from-file=ca.crt=certauthority.crt Note: certauthority.crt is the file available on the host machine when creating secret. ca.crt is the secret key that's getting created and when mounted to pod, it becomes the filename to the pod

Finally (before installing), update the values.yaml file

tls:
  enabled: true
  secret: "tls-openldap"
  CA:
    enabled: true
    secret: "tls-openldap-ca" 

After installing, helm --debug install -f values.yaml ldapdemorel stable/openldap, the openldap pod started successfully

[cinderblockgames]

ca.crt, server.crt, server.key

Looks like this is now ca.crt, ldap.crt, and ldap.key.

[xyrobo]

any one solve this problem? I came this problem in 1.5.0, when mount /container/service/slapd/assets/certs

[mvarchdev]

Same problem - cant use certificates and TLS support

[cr1cr1]

Unfortunately, It proved tough to solve. It does work if the cert files are hardcoded as names, or mapped in a container like described above. However, I have switched to https://github.com/tiredofit/docker-openldap.

Also, I have developed an ansible role to deploy openldap with multi-master replication in docker containers. Should in theory work with this release as well, but I did not maintained it anymore since the other one works as expected.

[christiansicari]

I am not adding nothing of new, but in summary we have to:

1. create certs

   
   echo "run command interactively"
   exit 1;
   openssl genrsa -des3 -out ca.key 2048
   openssl req -x509 -new -nodes -key ca.key -sha256 -days 1825 -out ca.crt

openssl genrsa -out server.key 2048 openssl req -new -key server.key -out server.csr openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 825 -sha256 openssl dhparam -out dhparam.pem 4096

Run the container mapping the certs
```bash
docker run -v $PWD/../certs:/container/service/slapd/assets/certs -e LDAP_TLS_DH_PARAM_FILENAME=dhparam.pem -e LDAP_TLS_CRT_FILENAME=server.crt -e LDAP_TLS_KEY_FILENAME=server.key -e LDAP_TLS_CA_CRT_FILENAME=ca.crt -v $PWD/volumes/ldap:/var/lib/ldap -v $PWD/volumes/slap.d:/etc/ldap/slapd.d --env LDAP_CONFIG_PASSWORD=adminpass   -p 389:389 -p 636:636 osixia/openldap:1.5.0 --copy-service