ports/159398: openssl slapd tls init def ctx failed: -1

[Harry Coin]

>Number:         159398
>Category:       ports
>Synopsis:       openssl slapd tls init def ctx failed: -1
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-ports-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 02 22:40:11 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:     Harry Coin
>Release:        8.2-STABLE
>Organization:
Quiet Fountain LLC
>Environment:
8.2-STABLE generic amd64
>Description:
openldap slapd fails to start at boot time, blocking directory server operations, every time under certain undocumented conditions.

If slapd.conf has

TLSCACertificatePath /some/legal/path/to/CACerts

and there exists even one file in that directory that is protected against reading by user ldap:ldap (such as perhaps the <ca name>.srl file for folk who have their own internal CA root certificates for signing multiple ldap servers, which openssl looks for in the same directory with the certificates) then:

../rc.d/slapd start fails to start, and the debug log has the obscure error

tls init def ctx failed: -1

This, even though all the certificates necessary for slapd operation are there and readable by the ldap user.  
>How-To-Repeat:
1. Use "openssl verify" ... to prove the certificates are good.
2. be sure one file exists in the TLSCACertificatePath directory that is not readable by user ldap:ldap.  The file can be anything, any length, unrelated to slapd operations, not even a certificate at all.

3. As root, run .../libexec/slapd manually and notice proper operations.

4. then notice failure every time running ../libexec/slapd -u ldap -g ldap
or .../rc.d/slapd start
>Fix:
Workaround: Make sure all the files in the certificate directory are readable by user LDAP, no matter what their purpose or content.

Otherwise, it needs a source fix.

>Release-Note:
>Audit-Trail:
>Unformatted: