Problemas de confiança de certificação do CentOS openLDAP

# LDAPTLS_CACERTDIR=/etc/ssl/certs/ ldapwhoami -x -ZZ -H ldaps://ldap.domain.tld
ldap_start_tls: Can't contact LDAP server (-1)
      additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user.

# openssl s_client -connect ldap.domain.tld:636 -CApath /etc/ssl/certs
<... successful tls negotiation stuff ...>
    Compression: 1 (zlib compression)
    Start Time: 1349994779
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

opensslparece achar que o certificado está bom, mas openldapas bibliotecas ( pam_ldapexibem comportamento semelhante, e foi assim que cheguei a essa bagunça) discordam.
O que estou fazendo de errado?

De fato, o RHEL não fornece nada que possa ser usado como um 'diretório de certificados' para fins de confiança da CA. Para o OpenSSL, um diretório de certificado - um 'CApath' - é um diretório que contém arquivos de certificado individuais (no formato PEM ou no formato 'certificado confiável' estendido do OpenSSL), com nomes em um formato específico com base em um hash do nome do sujeito do certificado. Geralmente, isso é alcançado colocando arquivos com nomes e .pemextensões legíveis por humanos em um diretório e executando c_rehashnele (consulteman c_rehash) Para o GnuTLS desde a versão 3.3.6 (antes disso, o GnuTLS não tinha suporte a diretórios), é apenas um diretório com arquivos PEM; O GnuTLS tentará carregar todos os arquivos no diretório e obter êxito em qualquer coisa PEM-ish (ele não pode lidar com o formato 'certificado confiável' do OpenSSL). Não tenho certeza absoluta de que o NSS possa realmente usar um diretório cheio de arquivos de certificado individuais como raiz de confiança, mas a documentação do OpenLDAP parece sugerir que sim (mas se o diretório também contiver um banco de dados do NSS, isso dará prioridade). Independentemente disso, o RHEL não possui nada como um diretório cheio de arquivos de certificado de CA individuais.

O Debian e derivativos fornecem /etc/ssl/certsneste formato; /etc/ssl/certsé o local canônico de armazenamento confiável no Debian, e na IMO qualquer coisa que o forneça deve ser basicamente o mesmo do Debian, pois o Debian tinha esse diretório organizado mais ou menos da mesma maneira desde 1999. RHEL tem um /etc/ssl/certsdiretório, mas está em não neste formato - ele não contém nenhum arquivo de certificado individual. Você não pode usá-lo como um CApath. Honestamente, no RHEL (e no Fedora e derivados) esse diretório é basicamente uma armadilha. Não use. (Consulte https://bugzilla.redhat.com/show_bug.cgi?id=572725 e https://bugzilla.redhat.com/show_bug.cgi?id=1053882para obter algumas informações sobre por que existe em primeiro lugar e como estou tentando corrigi-lo). Então eu acho que você está certo sobre o que está acontecendo, mas errado sobre o motivo. O OpenLDAP não está fazendo nada de errado e não está falhando porque "ca-bundle.trust.crt ... é um banco de dados de chaves / certificados Mozilla NSS" (são chamados cert8/9.dbe key3/4.db, e os do RHEL em todo o sistema /etc/pki/nssdb) , está apenas falhando porque /etc/ssl/certsnão pode ser usado como um 'diretório de certificado'.

O RHEL também não fornece nada utilizável como um armazenamento confiável no estilo CApath em qualquer outro lugar. O armazenamento confiável do sistema do RHEL é fornecido como um único arquivo de pacote configurável PEM (um 'CAfile' nos termos do OpenSSL), que pode ser encontrado em /etc/pki/tls/certs/ca-bundle.crte /etc/pki/tls/cert.pem. Ele também pode ser encontrado em /etc/ssl/certs/ca-bundle.crtcomo /etc/ssl/certsé na verdade apenas um link simbólico /etc/pki/tls/certs, mas esse local não é canônico e realmente não deve ser usado por nada. O RHEL também fornece um pacote no formato 'certificado confiável' do OpenSSL como /etc/pki/tls/certs/ca-bundle.trust.crt.

O correto, como você descobriu, é usar o arquivo do pacote que o sistema fornece. Sua resposta funcionará, mas pelas razões mencionadas acima, eu recomendo fortemente TLS_CACERT=/etc/pki/tls/certs/ca-bundle.crtou TLS_CACERT=/etc/pki/tls/cert.pemmais TLS_CACERT=/etc/ssl/certs/ca-bundle.crt.

(Não há nada de novo remotamente nisto, aliás, mas a confusão nas interwebs é generalizada. RH e derivados nunca forneceram um diretório cheio de certificados, nunca. Eles forneceram um arquivo de pacote desde o ano 2000. Era mudou de / usr / share / ssl para / etc / pki / tls em 2005. O Debian teve tanto /etc/ssl/certsum diretório no estilo CApath /etc/ssl/certs/ca-certificates.crtquanto um arquivo de pacote mais ou menos desde a idade da pedra.)

/etc/ssl/certs/contém /etc/ssl/certs/ca-bundle.trust.crtcomo parte de ca-certificates-2010.63-3.el6_1.5.noarch, que é um banco de dados de chaves / certificados Mozilla NSS. A inclusão desse arquivo dentro TLS_CACERTDIRfaz com que todos os outros arquivos sejam ignorados.

TLS_CACERTDIR
Especifica o caminho de um diretório que contém certificados de Autoridade de Certificação em arquivos individuais separados. O TLS_CACERT é sempre usado antes do TLS_CACERTDIR.` Este parâmetro é ignorado no GnuTLS.

Ao usar o Mozilla NSS, pode conter um banco de dados de certificado / chave do Mozilla NSS. Se contiver um banco de dados de certificados / chaves do Mozilla NSS e arquivos de certificação da CA, o OpenLDAP usará o banco de dados de certificados / chaves e ignorará os arquivos de certificados da CA.

No entanto, openldap-2.4.23-26.el6_3.2.i686parece não lidar com isso corretamente.

Resposta curta
Use LDAPTLS_CACERT=/etc/ssl/certs/ca-bundle.crt
(arquivo de configuração TLS_CACERT=/etc/ssl/certs/ca-bundle.crt)
Este arquivo também está incluído no arquivo ca-certificates-2010.63-3.el6_1.5.noarch.

Alguém mais se depara com isso; isto é o que funcionou para mim no centos 6 openldap e sssd:

notas: a. Alguns "espertos" decidiram fazer o sssd exigir TLS / SSL; mudança de comportamento de centos5; isso é ótimo para sistemas externos; mas quando você tiver mais de 300 nós no dispositivo interno com uma rede interna inacessível para o cluster da máquina; esse é um recurso de segurança extremamente inútil.

b. Além disso, certificados auto-chamuscados parecem não funcionar mais; vai continuar tentando

c. Evite o NSLCD a todo custo; foi atormentado com problemas ininterruptos quando defini o sinalizador legado e usei em vez de sssd (netgroups; syslog de deadlocking, etc.).

Para começar a funcionar usando sssd;

1. sssd.conf

   [domain/default]
   ldap_id_use_start_tls = True
   id_provider = ldap
   auth_provider = ldap
   chpass_provider = ldap
   cache_credentials = True
   ldap_search_base = dc=local
   enumerate = True
   ldap_uri = ldap://192.168.1.2/
   ldap_tls_cacertdir = /etc/openldap/cacerts
   ldap_tls_reqcert = allow
   ldap_schema = rfc2307bis
   

2. slapd.conf

   TLSCACertificateFile   /etc/openldap/cacerts/ca-bundle.crt
   TLSCertificateFile      /etc/openldap/cacerts/slapd.pem
   TLSCertificateKeyFile   /etc/openldap/cacerts/slapd.pem
   TLSCipherSuite HIGH:MEDIUM:-SSLv2
   

3. ldap.conf

   URI ldap://192.168.1.2/
   BASE dc=local
   
   TLS_CACERTDIR /etc/openldap/cacerts
   

Este é um problema muito comum, não se preocupe, eu tenho uma resposta para você.

Os primeiros clones do RHEL têm dois ldap.confarquivos, /etc/ldap.confou no RHEL6 está obsoleto, mas você pode usar /etc/nslcd.confpara autenticação agora /etc/openldap/ldap.confe apenas para consultas , por isso ldapsearch, ldapmodify, ldapremove, é realmente o seu perfil para que você não tem que ter uma cadeia longa desagradável cada vez que quiser para executar um comando ldap.

Agora, com isso fora do caminho, você tem dois parâmetros,

• tls_cacertfile - defina explicitamente o ca cert e você deve estar pronto
• tls_cacertdir - solte o ca cert no diretório, mas ele não funcionará, porque precisa ser hash ...

usar openssl x509 -hash -noout -in $file , ln -s $file $file.0, seu certificado CA funcionará.

Além disso Observe , se o arquivo de configuração estiver no CAPS, você estiver trabalhando em /etc/openldap/ldap.conf, eles são arquivos muito diferentes.

Espero que isso esclareça as coisas.

De acordo com todas as páginas de manual que eu já vi (mas não sou um usuário do CentOS), não existe LDAPTLS_CACERTDIR. A variável correta a ser definida é TLS_CACERTDIR. Você deve configurá-lo permanentemente no /etc/openldap/ldap.confCentOS ou onde ele mantém o arquivo de configuração da biblioteca LDAP. Além disso, pode ser necessário configurar o próprio pam-ldap para procurar os certificados da CA. /etc/pam_ldap.confAcho que no CentOS isso é , e a variável a ser configurada é tls_cacertdir.