O RHEL não fornece de fato nada que possa ser usado como um 'diretório de certificado' para fins de confiança da CA. Para o OpenSSL, um diretório de certificado - um 'CApath' - é um diretório contendo arquivos de certificado individuais (no formato PEM ou no formato 'certificado confiável' estendido do OpenSSL), com nomes em um formato específico baseado em um hash do nome do sujeito do certificado. Geralmente isso é obtido colocando arquivos com nomes legíveis por humanos e .pem extensions em um diretório e executando c_rehash (consulte man c_rehash ). Para o GnuTLS desde 3.3.6 (antes que o GnuTLS não tivesse suporte a diretório), é apenas um diretório com arquivos PEM nele; O GnuTLS irá tentar carregar todos os arquivos no diretório e ter sucesso em qualquer coisa PEM-ish (ele não pode lidar com o formato 'certificado confiável' do OpenSSL). Eu não tenho certeza se o NSS pode realmente usar um diretório cheio de arquivos de certificados individuais como uma raiz confiável de alguma forma, mas a documentação do OpenLDAP parece sugerir que pode (mas se o diretório também contiver um banco de dados NSS, ele dará essa prioridade). Independentemente disso, o RHEL não tem nada como um diretório cheio de arquivos de certificado de CA individuais.
Debian e derivados fornecem /etc/ssl/certs neste formato; /etc/ssl/certs é a localização do repositório de confiança canônico no Debian, e qualquer coisa que a IMO forneça deve basicamente ser descrita como a do Debian, já que o Debian tinha esse diretório apresentado mais ou menos da mesma forma desde 1999. O RHEL tem um /etc/ssl/certs diretório, mas não está neste formato - ele não contém nenhum arquivo de certificado individual. Você não pode usá-lo como um caminho de caminho. Honestamente, no RHEL (e no Fedora e derivados) esse diretório é basicamente uma armadilha. Não use isso. (Veja link e link para alguma informação sobre o porquê existe em primeiro lugar, e como eu estou tentando consertá-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 errado, e não está falhando porque "o ca-bundle.trust.crt ... é um banco de dados de certificados / chaves NSS do Mozilla" (esses são chamados cert8/9.db e key3/4.db , e o sistema inteiro no RHEL ao vivo em /etc/pki/nssdb ), ele está falhando porque /etc/ssl/certs não é utilizável como um 'diretório de certificados'.
O RHEL também não fornece nada que possa ser usado como um armazenamento confiável no estilo CApath em nenhum outro lugar. O armazenamento confiável do sistema do RHEL é fornecido como um único arquivo de pacote configurável PEM (um 'CAfile' em termos OpenSSL), que pode ser encontrado em /etc/pki/tls/certs/ca-bundle.crt e /etc/pki/tls/cert.pem . Ele também pode ser encontrado em /etc/ssl/certs/ca-bundle.crt as /etc/ssl/certs é na verdade apenas um link simbólico para /etc/pki/tls/certs , mas esse local não é canônico e realmente não deve ser usado por nada nunca. O RHEL também fornece um pacote no formato 'certificado confiável' do OpenSSL como /etc/pki/tls/certs/ca-bundle.trust.crt .
A coisa correta a fazer, como você descobriu, é usar o arquivo de pacote que o sistema fornece. Sua resposta funcionará, mas pelas razões mencionadas acima, recomendo vivamente TLS_CACERT=/etc/pki/tls/certs/ca-bundle.crt ou TLS_CACERT=/etc/pki/tls/cert.pem over TLS_CACERT=/etc/ssl/certs/ca-bundle.crt .
(Não há nada remotamente novo em nada disso, a propósito, mas a confusão nas interwebs é generalizada. A RH e os derivados nunca forneceram um diretório repleto de certificados. Eles forneceram um arquivo em pacote desde o ano 2000 Ele foi movido de / usr / share / ssl para / etc / pki / tls em 2005. O Debian teve tanto /etc/ssl/certs como um diretório no estilo CApath quanto /etc/ssl/certs/ca-certificates.crt como um arquivo de pacote mais ou menos desde a idade da pedra. )