У меня есть моментальный снимок виртуальной машины Centos 6.3 с настроенным LDAPS (openldap). Настроил несколько дней назад по советам из разных источников и потом все записал. Но когда я пытаюсь повторить установку (следуя своим собственным инструкциям), я не могу этого сделать: подтверждение SSL прерывается, как если бы сервер полностью неверно настроил сертификаты SSL. Похоже, если я указал конфигурацию сервера на несуществующий файл сертификата. Я выполняю все проверки локально (используя ldapsearch и "openssl s_client"). Что еще хуже, LDAPS на моем снимке перестает работать с той же проблемой после перезагрузки. Перезапуск служб slapd / nslcd / nscd без перезагрузки не приводит к его поломке 0_o Копирование точных конфигураций и сертификатов в чистый (без настройки LDAPS) снимок той же виртуальной машины и правильная конфигурация не работает. Вот почему проблема, похоже, не связана с конфигурацией и сертификатами. Я копал более 10 часов, но все еще очень хочу понять причину.
Для меня принципиально (поучительно) понять, почему возникает эта проблема только после перезагрузки а не после перезапуска службы. Пожалуйста, не стесняйтесь публиковать любые идеи о том, что сбрасывается до значений по умолчанию / разбивается / испортилось при перезагрузке хоста Linux. Другими словами, чем перезагрузка системы может отличаться от перезапуска службы в контексте отдельной службы, зафиксированной в моментальном снимке виртуальной машины?
Я уже проверил:
Может быть, причина в SELinux (возможно, он был отключен на моментальном снимке, завтра проверю на работе)
Есть другие предложения? Слишком устал, чтобы бороться дальше сегодня ...
Проблема действительно была вызвана SELinux сложным образом.
Для будущих людей, которые найдут этот ответ через Google, вот точный текст ошибки:
[root@va21 ~]# ldapsearch -d 1 -v -x -H ldaps://localhost:636
ldap_url_parse_ext(ldaps://localhost:636)
ldap_initialize( ldaps://localhost:636/??base )
ldap_create
ldap_url_parse_ext(ldaps://localhost:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP localhost:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 127.0.0.1:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: certdb config: configDir='/etc/openldap/certs' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly
TLS: using moznss security dir /etc/openldap/certs prefix .
TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory
TLS: error: connect - force handshake failure: errno 21 - moznss error -5938
TLS: can't connect: TLS error -5938:Encountered end of file.
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
и вывод openssl s_client:
[root@va21 ~]# openssl s_client -connect localhost:636 -showcerts
CONNECTED(00000003)
140066435413832:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 113 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
Это означает (это должно означать!), Что SSL-сертификаты недоступны / читаются / доступны / действительны при запуске сервера slapd.
Я готовил образ ВМ для QA-тестирования какого-то приложения. Это приложение отключает SELinux во время установки. Итак, у меня был отключен SELinux во время настройки openldap, и не было никаких проблем при размещении сертификатов в папке / certs.
Мои проблемы начались, когда мне пришлось развернуть openldap с той же конфигурацией на чистой виртуальной машине или перезагрузить существующую. Здесь был включен SELinux, и он не позволял slapd читать сертификаты из запрещенного места. Журналы обслуживания или выходные данные не содержали явных жалоб на отказ в разрешении. Я должен разместить сертификаты где-нибудь в / etc / ssl / certs / и / etc / openldap / certs, чтобы он работал.
Сбой SSL-соединений часто вызван рассинхронизацией времени. Виртуальные машины имеют тенденцию делать это, поэтому убедитесь, что вы запускаете ntpd на всех своих виртуальных машинах и что ntpdate запускается при загрузке до запуска ntpd.