[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP cannot start if some TLS cert value gets invalid

Nick Milas wrote:
On 12/2/2012 5:23 ÎÎ, Michael StrÃder wrote:

No! If one configures TLS support OpenLDAP must not start if any parameter
has an invalid value. One could think about starting solely with LDAPI
support to make back-config accessible.

Thanks Michael,

Let me ask, for clarification: If we have configured correctly TLS support,
and yet we bind like: "ldapsearch -H ldap://"; but not using -ZZ, this doesn't
mean that we will have a simple non-encrypted connection?

But what to do if a server configuration requires use of an encrypted connection? You're suggestion would require to temporarily enable encrypted connections which opens another can of worms.

In general I'm against adding more complexity to an implementation to *recover* from serious admin faults. I'm in favour of solely adding parameter validation to prevent admin faults. But this works only to some extent.

IMO your operational procedure should mandate that slapd has to be restarted
to test if any parameter was changed which affects startup. Or better in
your operational concept define a white-list of parameters allowed to be
changed via back-config without restart.

Any starting point for creating such a white-list of parameters?

The TLS parameters? ;-)

This ITS might also be interpreted that back-config should validate whether
all the TLS-related files are actually readable. But this is tricky because
slapd drops privileges after startup and at least the private key file is
likely not be readable by the slapd demon user.

A question on this: If the private cert is owned by root:root (and OpenLDAP
runs under ldap) (chmod 640 or 600 for security), my experience shows that
OpenLDAP will not read them (in CentOS, it is usually in
"/etc/pki/tls/private". So, I am using a copy of the private key, owned only
by ldap user, to make it readable by OpenLDAP. Should/could I do something

Yes, you're right. slapd's demon user already needs read access to the private key file. I've mixed it up with Apache's behaviour where the private key file can be owned by root and have permission 0600.

So back-config could check whether the TLS file parameter point to correct files (certs and keys) and refuse to change the attribute value. Still you can shoot yourself in the foot by moving away the files afterwards...

Ciao, Michael.