RHEL w rzeczywistości nie udostępnia niczego, co można by wykorzystać jako „katalog certyfikatów” dla celów zaufania urzędu certyfikacji. W przypadku OpenSSL katalog certyfikatów - „CApath” - to katalog zawierający pojedyncze pliki certyfikatów (w formacie PEM lub rozszerzonym formacie „zaufanego certyfikatu” OpenSSL), z nazwami w określonym formacie opartym na haszu nazwy podmiotu certyfikatu. Zwykle osiąga się to poprzez umieszczenie plików z nazwami i .pemrozszerzeniami czytelnymi dla człowieka w katalogu i uruchomienie c_rehashw nim (patrzman c_rehash). W przypadku GnuTLS od wersji 3.3.6 (wcześniej GnuTLS nie obsługiwał katalogów), jest to tylko katalog z plikami PEM; GnuTLS spróbuje załadować każdy plik w katalogu i odniesie sukces na dowolnym PEM-ie (nie obsługuje formatu „zaufanego certyfikatu” OpenSSL). Nie jestem do końca pewien, czy NSS może w jakiś sposób wykorzystać katalog pełen pojedynczych plików certyfikatów jako katalog główny zaufania, ale dokumentacja OpenLDAP wydaje się sugerować, że może (ale jeśli katalog zawiera również bazę danych NSS, da ten priorytet). Niezależnie od tego, RHEL nie ma czegoś takiego jak katalog pełen pojedynczych plików certyfikatów CA.
Debian i pochodne udostępniają /etc/ssl/certsw tym formacie; /etc/ssl/certsjest kanoniczną lokalizacją magazynu zaufania w Debianie, a IMO wszystko, co ją zapewnia, powinno zasadniczo ją ułożyć tak, jak Debian, ponieważ Debian ma ten katalog ułożony mniej więcej tak samo jak od 1999 roku. RHEL ma /etc/ssl/certskatalog, ale jest w nie w tym formacie - nie zawiera żadnych pojedynczych plików certyfikatów. Nie można go używać jako ścieżki CA. Szczerze mówiąc, na RHEL (i Fedorze i pochodnych) ten katalog jest w zasadzie pułapką. Nie używaj tego. (Zobacz https://bugzilla.redhat.com/show_bug.cgi?id=572725 i https://bugzilla.redhat.com/show_bug.cgi?id=1053882dla niektórych podstaw, dlaczego w ogóle istnieje i jak próbuję to naprawić). Myślę więc, że masz rację co do tego, co się dzieje, ale mylisz się co do przyczyny. OpenLDAP nie robi nic złego i nie zawodzi, ponieważ „ca-bundle.trust.crt ... to baza danych certyfikatów / kluczy Mozilla NSS” (te są nazywane cert8/9.dbi key3/4.db, i systemowe w RHEL na żywo /etc/pki/nssdb) , po prostu zawodzi, ponieważ w /etc/ssl/certsogóle nie nadaje się do „katalogu certyfikatów”.
RHEL nie zapewnia niczego, co mogłoby być użyteczne jako magazyn zaufania w stylu CApath nigdzie indziej. Systemowy magazyn zaufania RHEL jest dostarczany jako pojedynczy plik pakietu PEM („plik CA” w kategoriach OpenSSL), który można znaleźć na stronie /etc/pki/tls/certs/ca-bundle.crti /etc/pki/tls/cert.pem. Można go również znaleźć, /etc/ssl/certs/ca-bundle.crtponieważ /etc/ssl/certsjest to właściwie tylko dowiązanie symboliczne /etc/pki/tls/certs, ale ta lokalizacja nie jest kanoniczna i tak naprawdę nie powinna być używana przez nic. RHEL zapewnia również pakiet w formacie „zaufanego certyfikatu” OpenSSL jako /etc/pki/tls/certs/ca-bundle.trust.crt.
Jak się zorientowałeś, właściwym rozwiązaniem jest użycie pliku pakietu dostarczonego przez system. Twoja odpowiedź zadziała, ale z wyżej wymienionych powodów zdecydowanie polecam TLS_CACERT=/etc/pki/tls/certs/ca-bundle.crtlub TLS_CACERT=/etc/pki/tls/cert.pemprzeskoczę TLS_CACERT=/etc/ssl/certs/ca-bundle.crt.
(Nie ma w tym nic nowego, btw, ale zamieszanie w sieciach jest powszechne. RH i pochodne nigdy nie dostarczyły katalogu pełnego certyfikatów. Dostarczyły plik pakietu od 2000 roku. To był przeniesiony z / usr / share / ssl do / etc / pki / tls w 2005 roku. Debian ma zarówno /etc/ssl/certskatalog w stylu CApath, /etc/ssl/certs/ca-certificates.crtjak i plik pakietu mniej więcej od epoki kamienia łupanego.)