Cannot rerun with customized certificate at 1.1.1

[hsuhw]

Hi,

After moving to 1.1.1, I cannot rerun a container with my own certificate as I did on 1.1.0. I've also tried this on a newly created container (empty, with default settings) and it failed. There's no problem rerunning one with the default certificate though.

[osixia]

Hi,
Can you provide more information please, any logs or the command run ? Thx

[hsuhw]

After many times trying, I found something more specific:

At 1.1.0, when given customized certificate/key names longer than 12 chars (well, in fact I only tried on 13 v.s. 12), I can create a plain container by run, then stop and remove it, and then use run again with the same command (using the existing database) to rerun it. They all work properly if you try to connect to them.

This fails on 1.1.1 however. The first launch will still work properly, but after the first run & removing, I will get status Restarting (1) Less than x seconds ago each time I do run and check it with docker ps. Running it foreground, it will end with

...
*** Running /container/run/startup/:cfssl...
*** Running /container/run/startup/slapd...
Start OpenLDAP...
*** /container/run/startup/slapd failed with status 1

*** Killing all processes...

Weirdly, there's no problem for both 1.1.0 and 1.1.1 to rerun the image when given shorter certificate/key names (with length 12 chars I tried).

The script that I do the run and the testing is (providing it my own certificate, key and ca files)

#!/bin/bash

sudo docker run \
    --name openldap \
    --restart unless-stopped \
    -h example.org \
    -e LDAP_ORGANISATION='example' \
    -e LDAP_DOMAIN='example.org' \
    -e LDAP_TLS_CIPHER_SUITE='NORMAL' \
    -e LDAP_TLS_VERIFY_CLIENT='never' \
    -e LDAP_TLS_CRT_FILENAME='123456789.crt' \
    -e LDAP_TLS_KEY_FILENAME='123456789.key' \
    -e LDAP_TLS_CA_CRT_FILENAME='test_ca.pem' \
    -e LDAP_READONLY_USER='true' \
    -e LDAP_READONLY_USER_USERNAME='client' \
    -e LDAP_READONLY_USER_PASSWORD='mypasswd' \
    -v `pwd`/volumes/cert:/container/service/slapd/assets/certs \
    -v `pwd`/volumes/config:/etc/ldap/slapd.d \
    -v `pwd`/volumes/data:/var/lib/ldap \
    -p 636:636 \
    -d osixia/openldap

[deric]

I had same issue with 1.1.1, upgrade to 1.1.2 solves the crash (*** Killing all processes...), instead I'm getting this:

Waiting for OpenLDAP to start...
56ed2dc8 @(#) $OpenLDAP: slapd  (Jan 16 2016 23:00:08) $
    root@chimera:/tmp/buildd/openldap-2.4.40+dfsg/debian/build/servers/slapd
56ed2dc8 ldif_read_file: checksum error on "/etc/ldap/slapd.d/cn=config.ldif"
56ed2dc8 <= str2entry NULL (smr_normalize createTimestamp 21)
56ed2dc8 slapd stopped.
56ed2dc8 connections_destroy: nothing to destroy.

After deleting contents of both folders /etc/ldap/slapd.d and /var/lib/ldap it works. However when I restart the container the error appears again.

[baykovr]

+1 on this.

Recovered by manually importing LDIF's from the old cn=config and LDAP database.

[osixia]

guys, i have a bad new, this probably comes from sed -i '/olcTLS/d' /etc/ldap/slapd.d/cn\=config.ldif in startup.sh that partially remove the TLS configuration when "long" certificates filename are used.

To fix this you need to manually edit /etc/ldap/slapd.d/cn=config.ldif

for example in my tests i had a file like :

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 4cbc1891
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcLogLevel: none
olcPidFile: /var/run/slapd/slapd.pid
olcToolThreads: 1
structuralObjectClass: olcGlobal
entryUUID: f220831e-8eaf-1035-8784-fd61d4a623a6
creatorsName: cn=config
createTimestamp: 20160404125317Z
 y
entryCSN: 20160404125331.882761Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20160404125331Z

so i had to remove the line with the lonely y after that OpenLDAP started normally.

I will try to fix startup.sh asap :)

[drebes]

My cn=config.ldif file had:

createTimestamp: 20160319111056Z
 A1:-ARCFOUR-128
olcSecurity: tls=1

but removing the A1:-ARCFOUR-128 didn't help:

Add TLS config...
*** /container/run/startup/slapd failed with status 13

*** Killing all processes...

[PMLavigne]

I had the problem of the corrupt cn=config.ldif file, so I went in and manually removed the bad line as described, but now I'm getting the same issue as @drebes:

Jun 09 11:58:30 trip docker-run[9512]: Add TLS config...
Jun 09 11:58:30 trip docker-run[9512]: cfssl-helper is launched, everybody on the floor !
Jun 09 11:58:30 trip docker-run[9512]: Files [redacted - certificate] and [redacted - key] exists, fix files permissions
Jun 09 11:58:30 trip docker-run[9512]: 57599226 conn=1000 fd=17 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi)
Jun 09 11:58:30 trip docker-run[9512]: 57599226 conn=1000 op=0 BIND dn="" method=163
Jun 09 11:58:30 trip docker-run[9512]: 57599226 conn=1000 op=0 RESULT tag=97 err=13 text=TLS confidentiality required
Jun 09 11:58:30 trip docker-run[9512]: ldap_sasl_interactive_bind_s: Confidentiality required (13)
Jun 09 11:58:30 trip docker-run[9512]: *** /container/run/startup/slapd failed with status 13
Jun 09 11:58:30 trip docker-run[9512]: *** Killing all processes...

I also noticed that I had LDAP_TLS_ENFORCE: true, and when I change it to false the server starts normally and works fine. Oddly enough, TLS then works fine whenever I connect from a client.

[kopax]

Still not solved ? What happe if a cert name is "wildcard.domain.com.crt" ?

[jeremylongo]

-- edit : didn't read answer from osixia. My bad.

I had the problem today, as a simple workaround, use short filenames, like cert.key or cert.crt, which is within ldif max line length boundaries.

[kopax]

Hi @osixia, can we know if the long name certificate issue is solved?

I am willing to use long name and I am not sure if it is gonna break everything. Thanks in advance,