How do I renew an expired Ubuntu OpenLDAP SSL Certificate

Question

We went through the steps of revoking an SSL Certificate used by our OpenLDAP server and renewing it but we are unable to start slapd.

Here are the commands we used:

  openssl verify hostname_domain_com_cert.pem

We got back that the certificate was expired but "OK"

We revoked the certificate we'd been using:

  openssl ca -revoke /etc/ssl/certs/hostname_domain_com_cert.pem

Revoking worked fine.

We created the new Cert Request by passing it the key file as input:

  openssl req -new -key hostname_domain_com_key.pem -out newreq.pem

We generated a new certificate using the newly created request file "newreq.pem"

  openssl ca  -policy policy_anything -out newcert.pem -infiles newreq.pem

We looked at our cn=config.ldif file and found the locations for the key and cert and placed the newly dated certificate in the needed path.

Still we are unable to start slapd with:

  service slapd start

We get this message:

Starting OpenLDAP: slapd - failed.
The operation failed but no output was produced. For hints on what went
wrong please refer to the system's logfiles (e.g. /var/log/syslog) or
try running the daemon in Debug mode like via "slapd -d 16383" (warning:
this will create copious output).

Below, you can find the command line options used by this script to
run slapd. Do not forget to specify those options if you
want to look to debugging output:
  slapd -h 'ldap:/// ldapi:/// ldaps:///' -g openldap -u openldap -F /etc/ldap/slapd.d/

Here is what we found in /var/log/syslog

Oct 23 20:18:25 ldap1 slapd[2710]: @(#) $OpenLDAP: slapd 2.4.21 (Dec 19 2011 15:40:04) $#012#011buildd@allspice:/build/buildd/openldap-2.4.21/debian/build/servers/slapd
Oct 23 20:18:25 ldap1 slapd[2710]: main: TLS init def ctx failed: -1
Oct 23 20:18:25 ldap1 slapd[2710]: slapd stopped.
Oct 23 20:18:25 ldap1 slapd[2710]: connections_destroy: nothing to destroy.

After generating a new ldap1 key/cert pair now we get this whenever we try to start slapd

Oct 24 08:38:12 ldap1 slapd[5461]: @(#) $OpenLDAP: slapd 2.4.21 (Dec 19 2011 15:40:04) $#012#011buildd@allspice:/build/buildd/openldap-2.4.21/debian/build/servers/slapd
Oct 24 08:38:12 ldap1 slapd[5463]: hdb_db_open: database "cn=accesslog" cannot be opened, err 13. Restore from backup!
Oct 24 08:38:12 ldap1 slapd[5463]: bdb(cn=accesslog): txn_checkpoint interface requires an environment configured for the transaction subsystem
Oct 24 08:38:12 ldap1 slapd[5463]: bdb_db_close: database "cn=accesslog": txn_checkpoint failed: Invalid argument (22).
Oct 24 08:38:12 ldap1 slapd[5463]: backend_startup_one (type=hdb, suffix="cn=accesslog"): bi_db_open failed! (13)
Oct 24 08:38:13 ldap1 slapd[5463]: bdb_db_close: database "cn=accesslog": alock_close failed
Oct 24 08:38:13 ldap1 slapd[5463]: slapd stopped.

Should we try to restore ldap from backup?

Solution 1

Two things done to fix this...1) Create a new key/cert pair for the ldap1 server. 2) restore LDAP from a recent ** slapcat ** b/u.

Solution 2

There are a few possibilities here.

Is the new certificate really valid and verifiable against the issuing CA certificate?

What is the value of the attribute olctlscacertificatefile in your OpenLDAP configuration? In your case it should point to your root CA certificate, the one that signed the server's certificate. The proper value, however, would be /etc/ssl/certs/ca-certificates.crt where all trusted CA certificates are concatenated, yours included. See here for details: http://manpages.ubuntu.com/manpages/precise/man8/update-ca-certificates.8.html

It also could indicate a permission problem. Are the key and certificate (and parent paths) readable by the openldap user? Is the path of the key and certificate such that AppArmor doesn't complain? Check /var/log/kern.log for messages indicating that slapd tried to read a file outside of the paths AppArmor permits.

Edit: As per your updated question, which seems to have nothing to do with the original, it looks like you either messed up permissions in /var/lib/ldap or you really managed to corrupt one or more files in /var/lib/ldap. I say restore from backup.

Solution 3

A quick google search found this thread on the OpenLDAP mailing list. Anything related to your problem there?

Two suggestion there are:

• Check if the user that openldap is running as has permissions to read the certificate and key
• Append (or prepend) the issuing CA certificate to the newcert.pem file
• Try ldd $(which slapd) and see if your OpenLDAP is not linked against "gnutls", which may decide the order in which the root certificate is supposed to go into newcert.pem

Comments

[Michael Hampton]

You forgot the commands you used to place the certificate files in their final locations.

[daff]

OP mentioned in the title that he uses OpenLDAP on Ubuntu. Of note is also that Ubuntu and Debian don't compile OpenLDAP against OpenSSL, but against GnuTLS, in order to satisfy the GPL. Which leads to many interesting bugs, first and foremost this beast which has been in the works for over three years: bugs.launchpad.net/ubuntu/+source/sudo/+bug/423252

[Zhenya]

olcTLSCACertificateFile: /etc/ssl/certs/MyDomainCA.pem Its been working for some years this way. The perms seem to be right they are openldap openldap for the /etc/ldap/slapd.d folder and for /etc/ssl/private cert files are root ssl-cert with 777 and the certs folder is root root with 777. I believe the new files are using the same perms as those that have been working for some time. I'll add it to my question here.

[Zhenya]

Two things done to fix this...1) Create a new key/cert pair for the ldap1 server. 2) restore LDAP from a recent slapcat b/u.