RHEL non fornisce infatti nulla che possa essere utilizzato come "directory di certificati" a fini di affidabilità della CA. Per OpenSSL, una directory di certificati - un "CApath" - è una directory contenente singoli file di certificati (nel formato PEM o nel formato "certificato attendibile" esteso di OpenSSL), con nomi in un formato specifico basato su un hash del nome soggetto del certificato. Di solito questo si ottiene inserendo file con nomi ed .pemestensioni leggibili dall'uomo in una directory ed eseguendovi c_rehash(vedereman c_rehash). Per GnuTLS dalla 3.3.6 (prima che GnuTLS non avesse il supporto per le directory), è solo una directory con file PEM al suo interno; GnuTLS proverà a caricare tutti i file nella directory e avrà successo su qualsiasi PEM-ish (non è in grado di gestire il formato "certificato certificato" di OpenSSL). Sinceramente non sono sicuro che NSS possa effettivamente utilizzare una directory piena di singoli file di certificato come radice di trust in qualche modo, ma la documentazione di OpenLDAP sembra suggerire che può (ma se la directory contiene anche un database NSS darà quella priorità). Indipendentemente da ciò, RHEL non ha nulla di simile a una directory piena di singoli file di certificato CA.
Debian e derivati forniscono /etc/ssl/certsin questo formato; /etc/ssl/certsè la posizione canonica del deposito fiduciario su Debian, e tutto ciò che lo fornisce a IMO dovrebbe fondamentalmente disporlo come quello di Debian, dal momento che la directory di Debian ha organizzato quella directory più o meno allo stesso modo dal 1999. RHEL ha una /etc/ssl/certsdirectory, ma è in non in questo formato - non contiene alcun file di certificato individuale. Non puoi usarlo come CApath. Onestamente, su RHEL (e Fedora e derivati) quella directory è sostanzialmente una trappola. Non usarlo. (Vedi https://bugzilla.redhat.com/show_bug.cgi?id=572725 e https://bugzilla.redhat.com/show_bug.cgi?id=1053882per alcuni retroscena sul perché esiste in primo luogo e su come sto cercando di risolverlo). Quindi penso che tu abbia ragione su ciò che sta succedendo, ma sbagliato sul motivo per cui. OpenLDAP non sta facendo nulla di male, e non sta fallendo perché "ca-bundle.trust.crt ... è un database cert / chiavi Mozilla NSS" (quelli sono chiamati cert8/9.dbe key3/4.db, e quelli a livello di sistema su RHEL vivono /etc/pki/nssdb) , sta semplicemente fallendo perché /etc/ssl/certsnon è utilizzabile come "directory di certificato".
RHEL non fornisce nulla di utilizzabile come un negozio di fiducia in stile CApath altrove. Il truststore di sistema di RHEL è fornito come un singolo file bundle PEM (un 'CAfile' in termini OpenSSL), che può essere trovato su /etc/pki/tls/certs/ca-bundle.crte /etc/pki/tls/cert.pem. Può anche essere trovato in /etc/ssl/certs/ca-bundle.crtquanto /etc/ssl/certsè in realtà solo un collegamento simbolico a /etc/pki/tls/certs, ma quella posizione non è canonica e in realtà non dovrebbe essere utilizzata da nulla. RHEL fornisce anche un pacchetto nel formato "certificato certificato" di OpenSSL come /etc/pki/tls/certs/ca-bundle.trust.crt.
La cosa corretta da fare, come hai capito, è usare il file bundle fornito dal sistema. La tua risposta funzionerà, ma per i motivi sopra menzionati, ti consiglio vivamente TLS_CACERT=/etc/pki/tls/certs/ca-bundle.crto TLS_CACERT=/etc/pki/tls/cert.pemoltre TLS_CACERT=/etc/ssl/certs/ca-bundle.crt.
(Non c'è nulla di remoto in nulla di tutto questo, a proposito, ma la confusione sugli interwebs è diffusa. RH e derivati non hanno mai fornito una directory piena di certificati, mai. Hanno fornito un file bundle dal 2000. Era spostato da / usr / share / ssl a / etc / pki / tls nel 2005. Debian ha avuto sia /etc/ssl/certsuna directory in stile CApath /etc/ssl/certs/ca-certificates.crtche un file bundle più o meno dall'età della pietra.)