I also see this bug, and perhaps might be able to help find a reliable workaround.
I have OpenLDAP running on one etch system (called arch) and it does not show this bug. Unfortunately, arch is also my boundary router, so I don't want to leave LDAP running there. I am trying to migrate slapd to another system, also a fresh etch install, known as cohen. The setup is currently like this: arch runs slapd, and both arch and cohen authenticate against slapd using SSL to access ldaps://arch:636/. This all works. cohen also runs slapd, but it exhibits the problem described in this bug report, so I haven't moved any of the authentication to it yet. As far as I can make out, slapd is configured identically on the two machines. The ldap.conf and slapd.conf have both been copied from arch to cohen, with only the certificate and key file names and the host name changed in them. There are no differences in the permissions of any file below /etc/ldap between the two boxes. They both used certificates generated by the same CA using the same script. On arch, slapd runs as openldap.openldap and I can access it using ldap and ldaps protocols. On cohen, ldaps does not work unless I run slapd as root; the ldap protocol works for either user. I didn't do anything special on arch to workaround this problem, so I am a bit surprised that ldaps works on it. If you want to know anything about these two machines to try to figure out what is different to allow ldaps on one but not the other, please just ask. I will probably have a one- or two-day turnaround, but since this bug has been open for nearly 18 months I don't think it will be a problem ;-) Unfortunately, I can't give you logins on the boxes. Cheers, Tom Tom Cook OMS Test Engineer (08) 8480 8140 "Warning: The information contained in this email and any attached files is confidential to BAE Systems Australia. If you are not the intended recipient, any use, disclosure or copying of this email or any attachments is expressly prohibited. If you have received this email in error, please notify us immediately. VIRUS: Every care has been taken to ensure this email and its attachments are virus free, however, any loss or damage incurred in using this email is not the sender's responsibility. It is your responsibility to ensure virus checks are completed before installing any data sent in this email to your computer."
