Hi,
I found out that if, in a working OpenLDAP installation, we inadvertently change the value of:
olcTLSCertificateKeyFile: /path/to/key.pem
to some invalid value, like:
olcTLSCertificateKeyFile: /path/to/non/existing/key.pem
then OpenLDAP continues to work (and we see no error message whatsoever), but if it is stopped, it refuses to restart. In the logs, while OpenLDAP is starting, we see:
Feb 11 16:20:44 vdev slapd[15272]: main: TLS init def ctx failed: -1
and then service is immediately stopped.
I believe that in such cases at least OpenLDAP could start without TLS support, logging the problem and not being unable to restart.
The same should hold true for the other associated attributes (olcTLSCACertificateFile, olcTLSCertificateFile), for which I didn't test separately.
A workaround if this happens (because, since OpenLDAP server is not running, we cannot easily change the dynamic config) could be to create a symbolic link (/path/to/non/existing/key.pem)to the true file (/path/to/working/key.pem), and thus OpenLDAP can start.
Any comments/advice?
Thanks, Nick
Nick Milas wrote:
I found out that if, in a working OpenLDAP installation, we inadvertently change the value of:
olcTLSCertificateKeyFile: /path/to/key.pem
to some invalid value, like:
olcTLSCertificateKeyFile: /path/to/non/existing/key.pem
then OpenLDAP continues to work (and we see no error message whatsoever), but if it is stopped, it refuses to restart. In the logs, while OpenLDAP is starting, we see:
Feb 11 16:20:44 vdev slapd[15272]: main: TLS init def ctx failed: -1
and then service is immediately stopped.
I believe that in such cases at least OpenLDAP could start without TLS support,
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.
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.
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.
Ciao, Michael.
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
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 different?
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.
On 12/2/2012 11:58 μμ, Michael Ströder wrote:
So back-config could check whether the TLS file parameter point to correct files (certs and keys) and refuse to change the attribute value.
Right. Should I file an ITS for it?
Still you can shoot yourself in the foot by moving away the files afterwards...
Of course... In such cases, a clearer message in the logs, like "File /path/to/key.pem not found" would help very much. Current single message: "main: TLS init def ctx failed: -1" does imply that something is wrong with TLS config, esp. if it was working before, yet a more specific message would be valuable. Perhaps one can increase debug level and get more info, but I feel standard messages should avoid being cryptic.
Regards, Nick
Nick Milas wrote:
On 12/2/2012 11:58 μμ, Michael Ströder wrote:
So back-config could check whether the TLS file parameter point to correct files (certs and keys) and refuse to change the attribute value.
Right. Should I file an ITS for it?
I'm not an OpenLDAP project member. So it's up to you to decide. Personally I think it's worth an ITS with a feature request.
Ciao, Michael.
On 13/2/2012 12:32 μμ, Michael Ströder wrote:
Personally I think it's worth an ITS with a feature request.
I've filed http://www.openldap.org/its/index.cgi/Incoming?id=7164;page=12
Nick
openldap-technical@openldap.org
-
Michael Ströder -
Nick Milas