Назад | Перейти на главную страницу

Как продлить срок действия SSL-сертификата Ubuntu OpenLDAP с истекшим сроком действия

Мы выполнили этапы отзыва SSL-сертификата, используемого нашим сервером OpenLDAP, и его обновления, но запустить slapd не удалось.

Вот используемые нами команды:

  openssl verify hostname_domain_com_cert.pem

Мы получили ответ, что срок действия сертификата истек, но "ОК"

Мы отозвали сертификат, который использовали:

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

Отзыв прошел нормально.

Мы создали новый запрос сертификата, передав ему файл ключа в качестве входных данных:

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

Мы сгенерировали новый сертификат, используя только что созданный файл запроса "newreq.pem"

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

Мы просмотрели наш файл cn = config.ldif, нашли места для ключа и сертификата и поместили новый датированный сертификат по нужному пути.

Тем не менее мы не можем запустить slapd с:

  service slapd start

Получаем такое сообщение:

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/

Вот что мы нашли в / 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.

После генерации новой пары ключ / сертификат ldap1 теперь мы получаем это всякий раз, когда пытаемся запустить 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.

Стоит ли пытаться восстановить ldap из резервной копии?

Здесь есть несколько возможностей.

Действительно ли новый сертификат действителен и поддается проверке с помощью сертификата ЦС, выдавшего сертификат?

Какое значение атрибута olctlscacertificatefile в вашей конфигурации OpenLDAP? В вашем случае он должен указывать на ваш корневой сертификат CA, тот, который подписал сертификат сервера. Однако правильное значение будет /etc/ssl/certs/ca-certificates.crt где объединены все доверенные сертификаты CA, в том числе и ваш. Подробнее см. Здесь: http://manpages.ubuntu.com/manpages/precise/man8/update-ca-certificates.8.html

Это также может указывать на проблему с разрешением. Доступны ли ключ и сертификат (и родительские пути) для чтения openldap пользователь? Является ли путь ключа и сертификата таким, чтобы AppArmor не жаловался? Проверьте /var/log/kern.log для сообщений, указывающих, что slapd пытался прочитать файл за пределами разрешенных AppArmor путей.

редактировать: Согласно вашему обновленному вопросу, который, похоже, не имеет ничего общего с оригиналом, похоже, что вы либо испортили разрешения в /var/lib/ldap или вам действительно удалось испортить один или несколько файлов в /var/lib/ldap. Я говорю восстановить из резервной копии.

Найден быстрый поиск в Google эта тема в списке рассылки OpenLDAP. Есть что-нибудь, связанное с вашей проблемой?

Есть два предложения:

  • Проверьте, есть ли у пользователя, под которым запущен openldap, разрешения на чтение сертификата и ключа.
  • Добавить (или добавить) сертификат ЦС выдачи к newcert.pem файл
  • Пытаться ldd $(which slapd) и посмотрите, не связан ли ваш OpenLDAP с "gnutls", который может определять порядок, в котором предполагается, что корневой сертификат должен входить в newcert.pem

Чтобы исправить это, нужно сделать две вещи ... 1) Создайте новую пару ключ / сертификат для сервера ldap1. 2) восстановить LDAP из недавнего ** slapcat ** b / u.