[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP cannot start if some TLS cert value gets invalid
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? This means that the server offers this capability (unless
ACLs prevent it, with the exception of - as I have seen - root). So, why
not offer it if TLS is misconfigured? If client requires encryption, it
could issue: "ldapsearch -H ldap:// -ZZ" or "ldapsearch -H ldaps://"
which would fail if server does not offer TLS/SSL.
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?
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 different?
Thanks again,
Nick