Bug 159398 - security/openssl: openssl slapd tls init def ctx failed: -1
Summary: security/openssl: openssl slapd tls init def ctx failed: -1
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Bernard Spil
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-02 23:40 UTC by Harry Coin
Modified: 2018-10-31 22:10 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Harry Coin 2011-08-02 23:40:11 UTC
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.

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.
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, anyu
   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
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2011-08-03 03:01:19 UTC
State Changed
From-To: open->feedback

to which port does this PR apply?
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2011-08-05 03:46:38 UTC
Responsible Changed
From-To: freebsd-ports-bugs->dinoex

dinoex, please can you figure out if this applies to the port, or 
base, or both?  Thanks.
Comment 3 Dirk Meyer freebsd_committer freebsd_triage 2011-08-05 15:51:16 UTC
State Changed
From-To: feedback->analyzed


Comment 4 Dirk Meyer freebsd_committer freebsd_triage 2011-08-05 15:51:41 UTC
Responsible Changed
From-To: dinoex->delphij


This happens regradless of the version of OpenSSL (base or port). 
The mixed usage of that dir is an openldap issue.
Comment 5 Walter Schwarzenfeld freebsd_triage 2018-01-10 19:31:48 UTC
no statement since 2011-08-05. I can't imagine that this is still relevant.
Comment 6 Bernard Spil freebsd_committer freebsd_triage 2018-04-05 10:26:42 UTC
No responses from reporter, closing.
Comment 7 rainer 2018-10-31 22:10:09 UTC
I believe the actual openldap-issue still applies.

Just try out the tutorial in the handbook and you'll see.

It's true: the certs have to be moved to a different directory (or the key made globally readable).