De hecho, RHEL no proporciona nada que pueda usarse como un "directorio de certificados" para fines de confianza de CA. Para OpenSSL, un directorio de certificados, un 'CApath', es un directorio que contiene archivos de certificados individuales (en formato PEM o el formato de 'certificado de confianza' extendido de OpenSSL), con nombres en un formato específico basado en un hash del nombre del sujeto del certificado. Por lo general, esto se logra colocando archivos con nombres y .pemextensiones legibles por humanos en un directorio y ejecutándolo c_rehash(verman c_rehash) Para GnuTLS desde 3.3.6 (antes de eso, GnuTLS no tenía soporte de directorio), es solo un directorio con archivos PEM; GnuTLS intentará cargar cada archivo en el directorio y tendrá éxito en cualquier cosa PEM-ish (no puede manejar el formato de 'certificado de confianza' de OpenSSL). Honestamente, no estoy seguro de si NSS realmente puede usar un directorio lleno de archivos de certificados individuales como una raíz de confianza de alguna manera, pero la documentación de OpenLDAP parece sugerir que sí puede (pero si el directorio también contiene una base de datos NSS le dará esa prioridad). En cualquier caso, RHEL no tiene nada como un directorio lleno de archivos de certificados de CA individuales.
Debian y derivados proporcionan /etc/ssl/certsen este formato; /etc/ssl/certses la ubicación de la tienda de confianza canónica en Debian, y la OMI, todo lo que la proporcione debería básicamente presentarla como Debian, ya que Debian tenía ese directorio presentado más o menos de la misma manera desde 1999. RHEL tiene un /etc/ssl/certsdirectorio, pero está en no en este formato: no contiene ningún archivo de certificado individual. No puedes usarlo como un CApath. Honestamente, en RHEL (y Fedora, y derivados) ese directorio es básicamente una trampa. No lo uses (Ver https://bugzilla.redhat.com/show_bug.cgi?id=572725 y https://bugzilla.redhat.com/show_bug.cgi?id=1053882para algunos antecedentes sobre por qué existe en primer lugar y cómo estoy tratando de arreglarlo). Así que creo que tienes razón sobre lo que está sucediendo, pero equivocado sobre la razón por la cual. OpenLDAP no está haciendo nada mal, y no está fallando porque "ca-bundle.trust.crt ... es una base de datos cert / key de Mozilla NSS" (se llaman cert8/9.dby key3/4.db, y los de todo el sistema en RHEL viven /etc/pki/nssdb) , simplemente está fallando porque /etc/ssl/certsno se puede usar como un "directorio de certificados" en absoluto.
RHEL tampoco proporciona nada utilizable como una tienda de confianza de estilo CApath en ningún otro lugar. El almacén de confianza del sistema de RHEL se proporciona como un único archivo de paquete PEM (un 'CAfile' en términos de OpenSSL), que se puede encontrar en /etc/pki/tls/certs/ca-bundle.crty /etc/pki/tls/cert.pem. También se puede encontrar en, /etc/ssl/certs/ca-bundle.crtya /etc/ssl/certsque en realidad es solo un enlace simbólico /etc/pki/tls/certs, pero esa ubicación no es canónica y realmente nunca debería ser utilizada por nada. RHEL también proporciona un paquete en formato de 'certificado de confianza' de OpenSSL como /etc/pki/tls/certs/ca-bundle.trust.crt.
Lo que debe hacer, como descubrió, es utilizar el archivo de paquete que proporciona el sistema. Su respuesta funcionará, pero por las razones mencionadas anteriormente, lo recomendaría encarecidamente TLS_CACERT=/etc/pki/tls/certs/ca-bundle.crto TLS_CACERT=/etc/pki/tls/cert.pemmás TLS_CACERT=/etc/ssl/certs/ca-bundle.crt.
(No hay nada remotamente nuevo en nada de esto, por cierto, pero la confusión en las interwebs es generalizada. RH y derivados nunca han proporcionado un directorio lleno de certificados, nunca. Han proporcionado un archivo de paquete desde el año 2000. Fue se mudó de / usr / share / ssl a / etc / pki / tls en 2005. Debian ha tenido tanto /etc/ssl/certsun directorio de estilo CApath /etc/ssl/certs/ca-certificates.crtcomo un archivo de paquete más o menos desde la edad de piedra).