Como renovo um certificado SSL expirado do Ubuntu OpenLDAP?

Question

Passamos pelas etapas de revogar um certificado SSL usado pelo nosso servidor OpenLDAP e renová-lo, mas não conseguimos iniciar o slapd.

Aqui estão os comandos que usamos:

  openssl verify hostname_domain_com_cert.pem

Voltamos a confirmar que o certificado expirou, mas "OK"

Revogamos o certificado que estávamos usando:

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

A revogação funcionou bem.

Criamos a nova Solicitação de Certificação passando o arquivo-chave como entrada:

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

Geramos um novo certificado usando o arquivo de solicitação recém-criado "newreq.pem"

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

Analisamos nosso arquivo cn = config.ldif e encontramos os locais para a chave e o certificado e colocamos o certificado recém-datado no caminho necessário.

Ainda não conseguimos iniciar o slapd com:

  service slapd start

Recebemos esta mensagem:

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/

Aqui está o que encontramos em / 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.

Depois de gerar um novo par de chaves / certificados ldap1, agora obtemos isso sempre que tentamos iniciar o 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.

Devemos tentar restaurar o ldap a partir do backup?

    

Answer 1

Duas coisas feitas para corrigir isso ... 1) Crie um novo par chave / cert para o servidor ldap1. 2) restaurar o LDAP de um ** ** slapcat ** b / u recente.

    

Answer 2

Existem algumas possibilidades aqui.

O novo certificado é realmente válido e verificável em relação ao certificado da CA de emissão?

Qual é o valor do atributo olctlscacertificatefile em sua configuração do OpenLDAP? No seu caso, ele deve apontar para o seu certificado de CA raiz, aquele que assinou o certificado do servidor. O valor adequado, no entanto, seria /etc/ssl/certs/ca-certificates.crt em que todos os certificados de CA confiáveis são concatenados, inclusive seus. Consulte aqui para detalhes: link

Também pode indicar um problema de permissão. A chave e o certificado (e os caminhos pai) podem ser lidos pelo usuário openldap ? O caminho da chave e do certificado é tal que o AppArmor não se queixa? Verifique /var/log/kern.log para mensagens indicando que slapd tentou ler um arquivo fora dos caminhos permitidos pelo AppArmor.

Editar : de acordo com a sua pergunta atualizada, que parece não ter nada a ver com o original, parece que você desorganizou as permissões em /var/lib/ldap ou realmente conseguiu corromper um ou mais arquivos em /var/lib/ldap . Eu digo restaurar a partir do backup.

    

Answer 3

Uma rápida pesquisa no google encontrou este tópico na lista de discussão do OpenLDAP. Alguma coisa relacionada ao seu problema aí?

Duas sugestões são:

• Verifique se o usuário que o openldap está executando tem permissões para ler o certificado e a chave
• Anexar (ou pré-anexar) o certificado da CA de emissão ao arquivo newcert.pem
• Teste ldd $(which slapd) e veja se o seu OpenLDAP não está vinculado a "gnutls", o que pode decidir a ordem em que o certificado raiz deve entrar em newcert.pem