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

/etc/ssl/certs/ содержит /etc/ssl/certs/ca-bundle.trust.crt как часть ca-certificates-2010.63-3.el6_1.5.noarch, которая представляет собой базу данных сертификатов / ключей Mozilla NSS. Включение этого файла в TLS_CACERTDIR заставляет игнорировать все остальные файлы.

TLS_CACERTDIR
Задает путь к каталогу, который содержит сертификаты центра сертификации в отдельных отдельных файлах. TLS_CACERT всегда используется перед TLS_CACERTDIR. Этот параметр игнорируется GnuTLS.

При использовании Mozilla NSS может содержать базу данных сертификатов / ключей Mozilla NSS. Если он содержит базу данных сертификатов / ключей Mozilla NSS и файлы сертификатов ЦС, OpenLDAP будет использовать базу данных сертификатов / ключей и игнорировать файлы сертификатов ЦС.

Тем не мение, openldap-2.4.23-26.el6_3.2.i686 похоже, не справляется с этим должным образом.

Короткий ответ
Использовать LDAPTLS_CACERT=/etc/ssl/certs/ca-bundle.crt
(файл конфигурации TLS_CACERT=/etc/ssl/certs/ca-bundle.crt)
Этот файл также включен, предоставленный ca-certificates-2010.63-3.el6_1.5.noarch.

Кто-нибудь еще сталкивается с этим; это то, что сработало для меня на centos 6 openldap и sssd:

примечания: а. Какой-то «умник» решил заставить sssd требовать TLS / SSL; изменение поведения с centos5; это отлично подходит для внешних систем; но когда у вас есть более 300 узлов на внутреннем устройстве с недоступной внутренней сетью для машинного кластера; это крайне бесполезная функция безопасности.

б. Более того, самоподписанные сертификаты, похоже, больше не работают; продолжу попытки

c. Избегайте NSLCD любой ценой; мучили постоянные проблемы, когда я установил устаревший флаг и использовал вместо sssd (сетевые группы; системный журнал взаимоблокировок и т. д.).

Чтобы начать работу с помощью sssd;

1. sssd.conf

   [domain/default]
   ldap_id_use_start_tls = True
   id_provider = ldap
   auth_provider = ldap
   chpass_provider = ldap
   cache_credentials = True
   ldap_search_base = dc=local
   enumerate = True
   ldap_uri = ldap://192.168.1.2/
   ldap_tls_cacertdir = /etc/openldap/cacerts
   ldap_tls_reqcert = allow
   ldap_schema = rfc2307bis
   

2. slapd.conf

   TLSCACertificateFile   /etc/openldap/cacerts/ca-bundle.crt
   TLSCertificateFile      /etc/openldap/cacerts/slapd.pem
   TLSCertificateKeyFile   /etc/openldap/cacerts/slapd.pem
   TLSCipherSuite HIGH:MEDIUM:-SSLv2
   

3. ldap.conf

   URI ldap://192.168.1.2/
   BASE dc=local
   
   TLS_CACERTDIR /etc/openldap/cacerts
   

Это очень распространенная проблема, не волнуйтесь, у меня есть для вас ответ.

Первые клоны RHEL имеют два ldap.conf файлы, /etc/ldap.conf или в RHEL6 устарел, но вы можете использовать /etc/nslcd.conf для аутентификация сейчас /etc/openldap/ldap.conf только для запросы, так ldapsearch, ldapmodify, ldapremove, это действительно ваш профиль, поэтому вам не нужно иметь неприятную длинную строку каждый раз, когда вы хотите запустить команду ldap.

Теперь у вас есть два параметра:

• tls_cacertfile - явно определите сертификат CA, и все будет в порядке
• tls_cacertdir - поместите сертификат CA в каталог, но это не сработает, потому что потребности для хеширования ...

использовать openssl x509 -hash -noout -in $file , ln -s $file $file.0 , тогда ваш сертификат CA будет работать.

Также нота если файл конфигурации находится в CAPS, вы работаете в /etc/openldap/ldap.conf, это очень разные файлы.

Надеюсь, это проясняет ситуацию.

Согласно каждой странице руководства, которую я видел (но я не пользователь CentOS), не существует такой вещи, как LDAPTLS_CACERTDIR. Правильная переменная для установки: TLS_CACERTDIR. Вы должны установить его постоянно в /etc/openldap/ldap.conf или везде, где CentOS хранит файл конфигурации библиотеки LDAP. Кроме того, вам может потребоваться настроить сам pam-ldap для поиска сертификатов CA. В CentOS это /etc/pam_ldap.conf, Я думаю, и устанавливаемая переменная tls_cacertdir.