Проблемы доверия сертификата CentOS openLDAP

На самом деле 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, и ИМО все, что его предоставляет, должно в основном располагаться как в 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 года. Он был перемещен из / usr / share / ssl в / etc / pki / tls в 2005 году. В Debian были как / etc / ssl / certs в качестве каталога в стиле CApath, так и /etc/ssl/certs/ca-certificates.crt как файл пакета более или менее с тех пор, как каменный век.)