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.)