RHEL фактически не предоставляет ничего, что можно использовать в качестве «каталога сертификатов» для целей доверия CA. Для OpenSSL каталог сертификатов - «CApath» - это каталог, содержащий отдельные файлы сертификатов (в формате PEM или расширенном формате «доверенного сертификата» OpenSSL) с именами в определенном формате на основе хэша имени субъекта сертификата. Обычно это достигается путем помещения файлов с удобочитаемыми именами и .pemрасширениями в каталог и запуска c_rehashна нем (см.man c_rehash). Для GnuTLS начиная с 3.3.6 (до этого у GnuTLS не было поддержки каталогов), это просто каталог с файлами PEM; GnuTLS будет пытаться загрузить каждый файл в каталоге и успешно выполнить все операции PEM (он не может обрабатывать формат «доверенного сертификата» 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.
(Между прочим, в этом нет ничего отдаленно нового, но путаница между сетями широко распространена. RH и ее производные никогда не предоставляли каталог, полный сертификатов, никогда. Они предоставили пакетный файл с 2000 года. с 2005 года перенесен из / usr / share / ssl в / etc / pki / tls. Debian более или менее использовался /etc/ssl/certsкак каталог в стиле CApath и как пакетный /etc/ssl/certs/ca-certificates.crtфайл с каменного века.)