--On Wednesday, October 19, 2022 1:24 PM -0400 Timothy Stonis <
tim@stonis.com> wrote:
Hi,
I am trying to setup an OpenLDAP 2.6.3 server and I'd like to only use
olc configuration (no slapd.conf file). So far things are going okay, but
I'm having a problem with TLS configuration. I am able to enable TLS
using a self-signed certificate without any problem, however, if I try to
disable TLS using the following LDIF:
dn: cn=config
changetype: modify
delete: olcTLSCertificateFile
-
delete: olcTLSCertificateKeyFile
-
I get the following error:
modifying entry "cn=config"
ldap_modify: Server is unwilling to perform (53)
I enabled debugging and cannot seem to see the error. I have also tried
reordering the entries, doing one at a time, disabling ldaps:// binding,
etc but nothing seems to work. If I just remove the certificate and/or
key files, then the server does not start. Is enabling TLS a one way
street? Or, should I just use slapd.conf?
You could slapcat -n 0 -l config.ldif, remove the offending lines, and then use slapadd to re-import the configuration. What underlying TLS library is the server linked to?
Thanks for the suggestion. Prior, I tried using slapmodify to make the change, but I got the message the database was not writeable even running as root. Is there an ACL I need to set on cn=config to get slapmodify to work? It's linked against openssl 1.1.
As a second question, I read in an article online that there is a way to
store the TLS cert(s) and key in the LDAP database itself. However, I
cannot find any info on that in the documentation. Can anyone shed some
light on that?
You can store TLS certificates in LDAP, but that would not be the same as slapd using those certificates for its own operation. You can also look at the slapo-autoca overlay on how to use OpenLDAP as a centralized CA.
Okay, I got the info they could be used directly from: "For TLS, under 2.4 the filesystem location of the keys and certificates were stored in cn=config; as of 2.5, the keys and certificates themselves can be stored inside the database.” In this article: