Я попытался настроить свой openldap на безопасное соединение с помощью openssl в Debian5. Кстати, во время выполнения следующей команды у меня возникли проблемы. ldap: / etc / ldap # slapd -h 'ldap: // ldaps: //' -d1
>>> slap_listener(ldaps://)
connection_get(15): got connid=7
connection_read(15): checking for input on id=7
connection_get(15): got connid=7
connection_read(15): checking for input on id=7
connection_get(15): got connid=7
connection_read(15): checking for input on id=7
connection_get(15): got connid=7
connection_read(15): checking for input on id=7
connection_read(15): unable to get TLS client DN, error=49 id=7
connection_get(15): got connid=7
connection_read(15): checking for input on id=7
ber_get_next
ber_get_next on fd 15 failed errno=0 (Success)
connection_closing: readying conn=7 sd=15 for close
connection_close: conn=7 sd=15
Затем я ищу «не удалось получить клиентское DN TLS, ошибка = 49 id = 7», но, похоже, пока нет хорошего решения для этого. Пожалуйста помоги. Спасибо
#Что ж, я пытаюсь что-то исправить, чтобы заставить его работать, но теперь у меня есть этот ldap: ~ # slapd -d 256 -f /etc/openldap/slapd.conf @ (#) $ OpenLDAP: slapd 2.4.11 (26 ноября 2009 г., 09 : 17: 06) $ root @ SD6-Casa: /tmp/buildd/openldap-2.4.11/debian/build/servers/slapd не удалось определить конфигурационный файл "/etc/openldap/slapd.conf": такого файла нет или каталог (2) остановлен slapd. connections_destroy: нечего разрушать. Что мне теперь делать?
журнал : ldap: ~ # /etc/init.d/slapd start
Запуск OpenLDAP: slapd - не удалось.
Операция завершилась неудачно, но никаких выходных данных не было. Чтобы узнать, что пошло не так, обратитесь к файлам системного журнала (например, / var / log / syslog) или попробуйте запустить демон в режиме отладки, например, через "slapd -d 16383" (предупреждение: это создаст большой объем вывода).
Ниже вы можете найти параметры командной строки, используемые этим сценарием для запуска slapd. Не забудьте указать эти параметры, если хотите просмотреть выходные данные отладки: slapd -h 'ldaps: ///' -g openldap -u openldap -f /etc/ldap/slapd.conf
ldap:~# tail /var/log/messages Feb 8 16:53:27 ldap kernel: [ 123.582757] intel8x0_measure_ac97_clock: measured 57614 usecs Feb 8 16:53:27 ldap kernel: [ 123.582801] intel8x0: measured clock 172041 rejected Feb 8 16:53:27 ldap kernel: [ 123.582825] intel8x0: clocking to 48000 Feb 8 16:53:27 ldap kernel: [ 131.469687] Adding 240932k swap on /dev/hda5. Priority:-1 extents:1 across:240932k Feb 8 16:53:27 ldap kernel: [ 133.432131] EXT3 FS on hda1, internal journal Feb 8 16:53:27 ldap kernel: [ 135.478218] loop: module loaded Feb 8 16:53:27 ldap kernel: [ 141.348104] eth0: link up, 100Mbps, full-duplex Feb 8 16:53:27 ldap rsyslogd: [origin software="rsyslogd" swVersion="3.18.6" x-pid="1705" x-info="http://www.rsyslog.com"] restart Feb 8 16:53:34 ldap kernel: [ 159.217171] NET: Registered protocol family 10 Feb 8 16:53:34 ldap kernel: [ 159.220083] lo: Disabled Privacy Extensions
Прежде всего, ваш вопрос требует редактирования. Не ясно.
Было бы неплохо начать с рабочей установки без SSL, а затем добавлять части и фрагменты один за другим, пока что-то не сломается, чтобы вы могли найти проблему. Если проблема в том, что GnuTLS не поддерживает TLSCipherSuite, удалите его. Вам это действительно нужно? Почему вы настаиваете на OpenSSL? GnuTLS отлично работал у меня, включая LDAPS-соединения на порту 636, вам не нужен OpenSSL для этого.
Что касается этой ссылки http://wiki.debian.org/LDAP/OpenLDAPSetup В нем говорилось: «Диагностика: если вы попытаетесь установить сервер OpenLDAP (slapd) с Debian Lenny, он будет скомпилирован с использованием библиотеки GnuTLS. Это означает, что вы не можете использовать директиву стиля OpenSSL, такую как TLSCipherSuite HIGH: MEDIUM: -SSLv2 в slapd.conf. "
Я думаю, это означает, что на Debian5 (Lenny) нельзя использовать openssl в качестве защитного соединения. Может, поэтому я никогда этого не добиваюсь ... Вы, ребята, думаете, что это так?
Я бы проигнорировал сообщение «connection_read (15): не удалось получить DN клиента TLS, ошибка = 49 id = 7», если вы не изменили TLSVerifyclient по умолчанию, который по умолчанию «никогда».
На стороне клиента tls_reqcert по умолчанию - «требование».
Попробуйте добавить сертификат CA на стороне клиента или измените tls_reqcert на never.