RHEL насправді не забезпечує нічого, що може бути використано як "каталог сертифікатів" для цілей довіри CA. Для OpenSSL каталог сертифікатів - "CApath" - це каталог, що містить окремі файли сертифікатів (у форматі PEM або розширеному форматі "довіреного сертифіката" OpenSSL) з іменами у певному форматі, заснованому на хеші імені теми сертифіката. Зазвичай це досягається шляхом розміщення файлів із читаними людьми іменами та .pemрозширеннями в каталозі та запуском c_rehashна ньому (дивman c_rehash). Для GnuTLS з 3.3.6 (до цього GnuTLS не підтримував каталогів), це просто каталог з файлами PEM; GnuTLS буде намагатися завантажувати кожен файл у каталог і досягати успіху у будь-якому PEM-ish (він не може обробляти формат 'довіреного сертифіката' OpenSSL). Я не чесно впевнений, чи дійсно NSS може використовувати каталог, повний окремих файлів сертифікатів, як корень довіри, але документація OpenLDAP, здається, підказує, що може (але якщо каталог також містить базу даних NSS, він надасть цей пріоритет). Незважаючи на те, RHEL не має нічого подібного до каталогу, повної окремих файлів сертифікатів CA.
Debian та похідні продукти надаються /etc/ssl/certsв такому форматі; /etc/ssl/certsце канонічне розташування магазину довіри на Debian, і IMO все, що його забезпечує, в основному має викласти так, як Debian, так як у Debian цей каталог був викладений приблизно так само, як і в 1999 році. RHEL має /etc/ssl/certsкаталог, але він знаходиться в не в такому форматі - він взагалі не містить окремих файлів сертифікатів. Ви не можете використовувати його як CApath. Чесно кажучи, для RHEL (і Fedora, і похідних) цей каталог в основному є пасткою. Не використовуйте його. (Див. Https://bugzilla.redhat.com/show_bug.cgi?id=572725 та https://bugzilla.redhat.com/show_bug.cgi?id=1053882деякі відомості про те, чому воно існує в першу чергу, і як я намагаюся це виправити). Тож я думаю, ти маєш рацію щодо того, що відбувається, але помиляєшся з причини того, чому. OpenLDAP не робить нічого поганого, і це не виходить з ладу, тому що "ca-bundle.trust.crt ... - це серверна / ключова база даних Mozilla NSS" (такі називаються cert8/9.dbі key3/4.db, і в системі RHEL працюють всі /etc/pki/nssdb) , це просто не вдається, тому що він /etc/ssl/certsвзагалі не використовується як "каталог сертифікатів".
RHEL не надає нічого корисного в якості магазину довіри в стилі CApath. Система довіри магазину RHEL надається як єдиний файл пакету PEM ("CAfile" у термінах OpenSSL), який можна знайти на /etc/pki/tls/certs/ca-bundle.crtта /etc/pki/tls/cert.pem. Його можна також знайти /etc/ssl/certs/ca-bundle.crtяк, що /etc/ssl/certsє насправді просто символьним посиланням на /etc/pki/tls/certs, але це місце не є канонічним і насправді не повинно нічим використовувати. RHEL також надає пакет у форматі довіреного сертифіката OpenSSL як /etc/pki/tls/certs/ca-bundle.trust.crt.
Правильно, як ви зрозуміли, - використовувати файл пакету, який надає система. Ваша відповідь спрацює, але з причин, зазначених вище, я настійно рекомендую TLS_CACERT=/etc/pki/tls/certs/ca-bundle.crtабо TLS_CACERT=/etc/pki/tls/cert.pemбільше TLS_CACERT=/etc/ssl/certs/ca-bundle.crt.
(Нічого в цьому немає нічого віддаленого, btw, але плутанина в інтервеї є широко поширеною. RH та похідні ніколи не надавали каталог-повний сертифікатів. Вони надавали файл пакету з 2000 року. Це було переміщено з / usr / share / ssl в / etc / pki / tls у 2005 році. Debian /etc/ssl/certsз каменного віку мав як каталог у стилі CApath, так і /etc/ssl/certs/ca-certificates.crtяк файл пакету.)