openldap-bugs

openldap-bugs@openldap.org

1 participants
21517 discussions

Re: (ITS#5997) slapo-chain TLS issues
by michael＠stroeder.com 04 Mar '09

04 Mar '09

Quanah Gibson-Mount wrote: > --On Thursday, March 05, 2009 1:15 AM +0000 michael(a)stroeder.com wrote: > >> I take this ITS number since it seems you filed the same issue four >> times. AFAICS the others (ITS#5993, ITS#5995 and ITS#5996) should be >> ignored by everyone responding. > > Not really. if you check the ITS system, you'll see 5995, 5996, and > 5997 are all closed, marked as duplicates of 5993. Ah, sorry. Somebody was faster than me. Didn't see any response though. I'll repost to ITS#5993. Ciao, Michael.

1 0

Re: (ITS#5993) slapo-chain TLS issues
by michael＠stroeder.com 04 Mar '09

04 Mar '09

duramaxlb7(a)gmail.com wrote: > Master log file when slapo-chain runs > --------------- > TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert > unknown ca. > > Slave log file when slapo-chain runs > ----------------- > TLS: can't connect: error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. To me both messages look like the trusted CA cert (directory) is not properly configured. > I had the same problem with LUMA and that problem went away when I put the > starttls=critical in the chain-idassert-bind Hmm, are you sure you didn't add "tls_cacertdir=/etc/openldap/cacerts" to chain-idassert-bind at the same time when testing? Ciao, Michael.

1 0

Re: (ITS#5997) slapo-chain TLS issues
by quanah＠zimbra.com 04 Mar '09

04 Mar '09

--On Thursday, March 05, 2009 1:15 AM +0000 michael(a)stroeder.com wrote: > I take this ITS number since it seems you filed the same issue four > times. AFAICS the others (ITS#5993, ITS#5995 and ITS#5996) should be > ignored by everyone responding. Not really. if you check the ITS system, you'll see 5995, 5996, and 5997 are all closed, marked as duplicates of 5993. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5997) slapo-chain TLS issues
by michael＠stroeder.com 04 Mar '09

04 Mar '09

I take this ITS number since it seems you filed the same issue four times. AFAICS the others (ITS#5993, ITS#5995 and ITS#5996) should be ignored by everyone responding. duramaxlb7(a)gmail.com wrote: > Master log file when slapo-chain runs > --------------- > TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert > unknown ca. > > Slave log file when slapo-chain runs > ----------------- > TLS: can't connect: error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. To me both messages look like the trusted CA cert (directory) is not properly configured. > I had the same problem with LUMA and that problem went away when I put the > starttls=critical in the chain-idassert-bind Hmm, are you sure you didn't add "tls_cacertdir=/etc/openldap/cacerts" to chain-idassert-bind at the same time when testing? Ciao, Michael.

1 0

(ITS#5997) slapo-chain TLS issues
by duramaxlb7＠gmail.com 04 Mar '09

04 Mar '09

Full_Name: Chad Richards Version: 2.4.15 OS: CentOS 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.178.116.129) overlay chain chain-rebind-as-user FALSE chain-uri "ldap://XXX" chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=Manager,dc=XXX,dc=com" credentials="secret" mode="self" starttls=critical tls_reqcert=never tls_cacertdir=/etc/openldap/cacerts chain-tls start chain-return-error TRUE slapo-chain and TLS work fine connecting to the slave with LUMA, I can do password updates and everything is fine. At first TLS slapo-chain wouldn't work in LUMA until I added starttls=critical inside chain-idassert-bind Now the problem I'm having is that I cannot do a passwd as root or an ldap user from the shell prompt. ldap.conf ssl start_tls tls_reqcert never tls_checkpeer no tls_cacertdir /etc/openldap/cacerts Master log file when slapo-chain runs --------------- TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(18): got connid=6 connection_read(18): checking for input on id=6 TLS trace: SSL3 alert read:fatal:unknown CA TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca. connection_read(18): TLS accept failure error=-1 id=6, closing connection_close: conn=6 sd=18 Slave log file when slapo-chain runs ----------------- TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 19, subject: /C=US/ST=XX/O=XX/OU=XX/CN=XX/emailAddress=XX, issuer: /C=US/ST=XX/O=XX/OU=XX/CN=XX/emailAddress=XX TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. I had the same problem with LUMA and that problem went away when I put the starttls=critical in the chain-idassert-bind my ldap.conf works fine for everything else but just dies on passwd with TLS errors with slapo-chain. Any ideas? Thanks!

1 0

(ITS#5996) slapo-chain TLS issues
by duramaxlb7＠gmail.com 04 Mar '09

04 Mar '09

1 0

(ITS#5995) slapo-chain TLS issues
by duramaxlb7＠gmail.com 04 Mar '09

04 Mar '09

1 0

(ITS#5994) replica segfault after syncing final entry
by quanah＠zimbra.com 04 Mar '09

04 Mar '09

Full_Name: Quanah Gibson-Mount Version: 2.3.43 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) With a replica doing a full refresh from the master, it segfaults on the final entry. The line in question is: rc = bdb_cache_find_id( op, ltid, eip->bei_id, &eip, 0, locker, &plock ); Core data: Program terminated with signal 11, Segmentation fault. #0 0x00002aaaaf76ddee in bdb_delete (op=0x41000840, rs=0x41000430) at delete.c:178 There is only one active thread in the core: (gdb) thr apply all bt Thread 4 (process 23189): #0 0x0000003167a075b5 in pthread_join () from /lib64/libpthread.so.0 #1 0x00002aaaaaabd817 in ldap_pvt_thread_join (thread=1082132800, thread_return=0x0) at thr_posix.c:193 #2 0x0000000000429c79 in slapd_daemon () at daemon.c:2579 #3 0x0000000000412183 in main (argc=10, argv=0x7fffca15ec78) at main.c:859 Thread 3 (process 23190): #0 0x0000003166ecec48 in ?? () #1 0x0000000000000000 in ?? () Thread 2 (process 23192): #0 0x0000003167a0a4a6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002aaaaaabd8c4 in ldap_pvt_thread_cond_wait (cond=0x6579a50, mutex=0x6579a28) at thr_posix.c:299 #2 0x00002aaaaaabc609 in ldap_int_thread_pool_wrapper (xpool=0x6579a20) at tpool.c:466 #3 0x0000003167a062f7 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003166ece85d in ?? () #5 0x0000000000000000 in ?? () Thread 1 (process 23191): #0 0x00002aaaaf76ddee in bdb_delete (op=0x41000840, rs=0x41000430) at delete.c:178 #1 0x00000000004a0fe9 in overlay_op_walk (op=0x41000840, rs=0x41000430, which=op_delete, oi=0x66a3550, on=0x0) at backover.c:650 #2 0x00000000004a11ec in over_op_func (op=0x41000840, rs=0x41000430, which=op_delete) at backover.c:702 #3 0x00000000004a1336 in over_op_delete (op=0x41000840, rs=0x41000430) at backover.c:754 #4 0x00000000004985fc in syncrepl_del_nonpresent (op=0x41000840, si=0x66a3170, uuids=0x0, cookiecsn=0x41000640) at syncrepl.c:2167 #5 0x0000000000493849 in do_syncrep2 (op=0x41000840, si=0x66a3170) at syncrepl.c:823 #6 0x00000000004946e9 in do_syncrepl (ctx=0x41000e00, arg=0x66a3350) at syncrepl.c:1102 #7 0x00002aaaaaabc56a in ldap_int_thread_pool_wrapper (xpool=0x6579a20) at tpool.c:478 #8 0x0000003167a062f7 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003166ece85d in ?? () #10 0x0000000000000000 in ?? () The operation data is: (gdb) print *op $1 = {o_hdr = 0x410009a0, o_tag = 74, o_time = 1236201040, o_tincr = 2166, o_bd = 0x41000080, o_req_dn = {bv_len = 0, bv_val = 0x6902820 ""}, o_req_ndn = {bv_len = 0, bv_val = 0x6b8dcd0 ""}, o_request = {oq_add = {rs_e = 0x2, rs_modlist = 0xffffffffffffffff}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 18446744073709551615, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x41000370 "\t"}, rb_ssf = 159460192, rb_tmp_mech = {bv_len = 15, bv_val = 0x66a2ac0 "(objectclass=*)"}}, oq_compare = {rs_ava = 0x2}, oq_modify = { rs_modlist = 0x2, rs_increment = -1}, oq_modrdn = {rs_newrdn = {bv_len = 2, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x41000370, rs_nnewSup = 0x9812b60, rs_deleteoldrdn = 15}, oq_search = {rs_scope = 2, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x41000370, rs_filter = 0x9812b60, rs_filterstr = {bv_len = 15, bv_val = 0x66a2ac0 "(objectclass=*)"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = { rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = { rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 1090519920, bv_val = 0x9812b60 "�5\221\t"}, rs_new = {bv_len = 15, bv_val = 0x66a2ac0 "(objectclass=*)"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_ctrlflag = '\0' <repeats 12 times>, "\002", '\0' <repeats 18 times>, o_controls = 0x41000a18, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x66a2690 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x66a0a20 "cn=config"}, sai_ssf = 256, sai_transport_ssf = 0, sai_tls_ssf = 256, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x980ebf0, o_ctrls = 0x0, o_csn = {bv_len = 32, bv_val = 0x9417220 "20090304090011Z#000000#00#000000"}, o_private = 0x40fffef0, o_next = {stqe_next = 0x0}} (gdb) print *ltid $3 = {mgrp = 0x675ea50, parent = 0x0, last_lsn = {file = 0, offset = 0}, txnid = 2147483701, tid = 0, off = 16056, lock_timeout = 0, expire = 0, txn_list = 0x0, links = {tqe_next = 0x0, tqe_prev = 0x675ea58}, xalinks = {tqe_next = 0x0, tqe_prev = 0x0}, events = {tqh_first = 0x0, tqh_last = 0x68dc978}, logs = {stqh_first = 0x0, stqh_last = 0x68dc988}, kids = { tqh_first = 0x0, tqh_last = 0x68dc998}, klinks = {tqe_next = 0x0, tqe_prev = 0x0}, api_internal = 0x0, cursors = 0, abort = 0x2aaaafa4ca70 <__txn_abort_pp>, commit = 0x2aaaafa4caf0 <__txn_commit_pp>, discard = 0x2aaaafa4c9f0 <__txn_discard_pp>, id = 0x2aaaafa4a690 <__txn_id>, prepare = 0x2aaaafa4bf70 <__txn_prepare>, set_timeout = 0x2aaaafa4b0b0 <__txn_set_timeout>, flags = 16} And here's the last few lines of debug output when I ran slapd with '-d32767': => test_filter PRESENT => access_allowed: search access to "cn=serverX,cn=servers,cn=zimbra" "objectClass" requested <= root access granted <= test_filter 6 send_ldap_result: conn=-1 op=0 p=3 send_ldap_result: err=0 matched="" text="" ==> bdb_delete: bdb_dn2entry("") entry_decode: "" <= entry_decode() (serverX is the last dn in an ldif produced with slapcat, and it's also the name of the replica server).

1 0

(ITS#5993) slapo-chain TLS issues
by duramaxlb7＠gmail.com 04 Mar '09

04 Mar '09

1 0

(ITS#5992) libldap with gnutls don't trust V1 CAs.
by mathias.gug＠canonical.com 04 Mar '09

04 Mar '09

Full_Name: Mathias Gug Version: 2.4.15 OS: Ubuntu Linux (Jaunty - 9.04) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.56.226.136) Starting with GnuTLS 2.6.3, V1 CA certs are no longer trusted by default when a CA chain is checked. Thus libldap+gnutls breaks in existing environement when one of the CA certs uses a V1 certificate. However libldap+openssl still supports V1 certificates in the CA chain. See https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/305264 for more information. Could libldap+gnutls be updated to also support V1 CA certificates to match features provided by libldap+openssl? To reproduce: 0. Need two versions of openldap : one compiled with gnutls, the other with openssl. 1. Create a V1 CA. 2. Create a certificate to be used by slapd and sign it with the V1 CA. 3. Configure a slapd+openssl system with certificates issues above. 4. Try to connect to the slapd+openssl system with a libldap+gnutls client: mathiaz@t-slapd-gnutls:~$ ldapsearch -b "dc=vmnet" -D "cn=admin,dc=vmnet" -x -w mypwd -H ldaps://t-slapd-openssl./ -d 1 ldap_url_parse_ext(ldaps://t-slapd-openssl./) ldap_create ldap_url_parse_ext(ldaps://t-slapd-openssl.:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP t-slapd-openssl.:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.42.220:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS: peer cert untrusted or revoked (0x82) TLS: can't connect: (unknown error code). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) On a system with libldap+openssl: mathiaz@t-slapd-openssl:~$ ldapsearch -b "dc=vmnet" -D "cn=admin,dc=vmnet" -x -w mypwd -H ldaps://t-slapd-openssl./ # extended LDIF # # LDAPv3 # base <dc=vmnet> with scope subtree # filter: (objectclass=*) # requesting: ALL # # vmnet dn: dc=vmnet objectClass: top objectClass: dcObject objectClass: organization o: vmnet dc: vmnet # admin, vmnet dn: cn=admin,dc=vmnet objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: e2NyeXB0fWtlVHlnV1lleFBDWFU= # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 $ ldapsearch is able to connect to the slapd+openssl server.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs