CentOS OpenLDAP удостоверяет вопросы доверия

# LDAPTLS_CACERTDIR=/etc/ssl/certs/ ldapwhoami -x -ZZ -H ldaps://ldap.domain.tld
ldap_start_tls: Can't contact LDAP server (-1)
      additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user.

# openssl s_client -connect ldap.domain.tld:636 -CApath /etc/ssl/certs
<... successful tls negotiation stuff ...>
    Compression: 1 (zlib compression)
    Start Time: 1349994779
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

opensslкажется, что сертификат в порядке, но openldapбиблиотеки ( pam_ldapдемонстрирующие схожее поведение, как я понял в этом беспорядке) не согласны.
Что я делаю неправильно?

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файл с каменного века.)

/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 и файлы сертификатов CA, OpenLDAP будет использовать базу данных сертификатов / ключей и будет игнорировать файлы сертификатов CA.

Тем 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 OpenLADAP и SSSD:

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

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

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

Чтобы начать работать с 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 - четко определите сертификат, и вы должны хорошо идти
• tls_cacertdir- поместите сертификат в каталог, но он не будет работать, потому что его нужно хешировать ...

используйте 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. /etc/pam_ldap.confЯ думаю, что в CentOS это и переменная для установки tls_cacertdir.