- openldap-bugs - openldap.org

Re: (ITS#6002) slaptest dynlist conversion problem
by hyc＠symas.com 05 Mar '09

05 Mar '09

derek(a)umiacs.umd.edu wrote: > Full_Name: Derek Yarnell > Version: 2.4.15 > OS: Red Hat Enterprise Linux 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.8.120.187) > > > When I go to create a slapd.d cn=config directory with the following in my bdb > database using the dynlist overlay, > > overlay dynlist > dynlist-attrset groupOfNames labeledURI member > > I get the following portion of the cn=config directory structure, > > # cat olcOverlay\=\{1\}dynlist.ldif > dn: olcOverlay={1}dynlist > objectClass: olcOverlayConfig > objectClass: olcDynamicList > olcOverlay: {1}dynlist > olcDlAttrSet: {0}groupOfNames groupOfNames member > structuralObjectClass: olcDynamicList > entryUUID: 6daa3d54-ec05-432a-bdf0-9d3ded5aed23 > creatorsName: cn=config > createTimestamp: 20090305215204Z > entryCSN: 20090305215204.399170Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20090305215204Z > > The problem is that olcDlAttrSet this is not right and the 2nd groupOfNames > should be labeledURI. This obviously causes slapd to not start correctly and I > have to hand correct. > Thanks for the report, now fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6002) slaptest dynlist conversion problem
by derek＠umiacs.umd.edu 05 Mar '09

05 Mar '09

Full_Name: Derek Yarnell Version: 2.4.15 OS: Red Hat Enterprise Linux 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.8.120.187) When I go to create a slapd.d cn=config directory with the following in my bdb database using the dynlist overlay, overlay dynlist dynlist-attrset groupOfNames labeledURI member I get the following portion of the cn=config directory structure, # cat olcOverlay\=\{1\}dynlist.ldif dn: olcOverlay={1}dynlist objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {1}dynlist olcDlAttrSet: {0}groupOfNames groupOfNames member structuralObjectClass: olcDynamicList entryUUID: 6daa3d54-ec05-432a-bdf0-9d3ded5aed23 creatorsName: cn=config createTimestamp: 20090305215204Z entryCSN: 20090305215204.399170Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090305215204Z The problem is that olcDlAttrSet this is not right and the 2nd groupOfNames should be labeledURI. This obviously causes slapd to not start correctly and I have to hand correct.

1 0

Re: (ITS#5966) test056 may miss the current connection
by quanah＠zimbra.com 05 Mar '09

05 Mar '09

--On Thursday, March 05, 2009 9:05 PM +0000 quanah(a)zimbra.com wrote: > --On Saturday, February 21, 2009 2:50 PM +0000 ando(a)sys-net.it wrote: > >> Full_Name: Pierangelo Masarati >> Version: HEAD >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.63.140.131) >> Submitted by: ando >> >> >> One every few runs (1/75 roughly) test056 does not read the current >> connection from slapd, thus failing the check for the monitor1.out block. >> >> The "cn=Connection 1,cn=Connections,cn=Monitor" entry appears to be >> missing from the results returned when searching the subtree rooted at >> "cn=Connections,cn=Monitor". >> >> Not clear how this can happen, the logs do not show enough details, and >> the behavior is too erratic to trace. > > It seems to be missing a lot. I get hundreds of: > slapd-read PID=10541: ldap_search_ext_s(cn=Database > 1,cn=Databases,cn=Monitor): No such object (32) > matched: cn=Databases,cn=Monitor test039 is one of several where I see this: slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor slapd-read PID=29590: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor PID=29590 - Read done (32). PID=29604 - Bind done (0). PID=29576 - Search done (0). PID=18701 - Add/Delete done (0). PID=18699 - Modrdn done (0). PID=18656 - Search done (0). PID=18627 - Add/Delete done (0). PID=18615 - Search done (0). PID=24501 - Search done (0). PID=25038 - Search done (0). PID=24259 - Search done (0). PID=21968 - Search done (0). PID=25300 - Search done (0). PID=25898 - Search done (0). PID=27976 - Search done (0). PID=18617 - Modrdn done (0). PID=18646 - Modrdn done (0). Using ldapsearch to retrieve all the entries... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... >>>>> Test succeeded --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5966) test056 may miss the current connection
by quanah＠zimbra.com 05 Mar '09

05 Mar '09

--On Saturday, February 21, 2009 2:50 PM +0000 ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > Submitted by: ando > > > One every few runs (1/75 roughly) test056 does not read the current > connection from slapd, thus failing the check for the monitor1.out block. > > The "cn=Connection 1,cn=Connections,cn=Monitor" entry appears to be > missing from the results returned when searching the subtree rooted at > "cn=Connections,cn=Monitor". > > Not clear how this can happen, the logs do not show enough details, and > the behavior is too erratic to trace. It seems to be missing a lot. I get hundreds of: slapd-read PID=10541: ldap_search_ext_s(cn=Database 1,cn=Databases,cn=Monitor): No such object (32) matched: cn=Databases,cn=Monitor --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6001) SID of queued CSN must match that of op
by rein＠OpenLDAP.org 05 Mar '09

05 Mar '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein All CSNs in the queue is currently considered when committed CSNs are fetched. This creates race conditions where a CSN not matching the current op could be returned. A fix that only considers CSNs with the same SID as the one in the op is coming. Rein Tollevik Basefarm AS

1 0

Re: (ITS#6000) slapadd allows to add entry with empty DN
by ando＠sys-net.it 05 Mar '09

05 Mar '09

hyc(a)symas.com wrote: >> When slapd is configured to host a database with empty suffix (""), an entry >> with empty DN can be slapadd'ed, but not ldapadd'ed. I believe the latter >> behavior is appropriate, while the former should be denied. > > No, you need to be able to slapadd the context entry, in particular to restore > a contextCSN. OK, but then no corresponding add operation can be performed, as far as I understand. I think we should provide a means to allow this operation, e.g. with a specific control. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6000) slapadd allows to add entry with empty DN
by quanah＠zimbra.com 05 Mar '09

05 Mar '09

--On Thursday, March 05, 2009 4:58 PM +0000 ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > When slapd is configured to host a database with empty suffix (""), an > entry with empty DN can be slapadd'ed, but not ldapadd'ed. I believe the > latter behavior is appropriate, while the former should be denied. I disagree. When you configure a database with "", and you slapcat it, it generates the empty suffix entry, which is used to store the contextCSN for replication. You *must* be able to export it and reload it for sync-replication. For example, from slapcat: dn: objectClass: glue structuralObjectClass: glue contextCSN: 20060825091501Z#000000#00#000000 entryCSN: 20060825091501Z#000000#00#000000 modifiersName: uid=zimbra,cn=admins,cn=zimbra modifyTimestamp: 20060825091501Z entryUUID: 956a60ba-c8a6-102a-86ac-5d3a048562c0 creatorsName: uid=zimbra,cn=admins,cn=zimbra createTimestamp: 20060825165749Z --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6000) slapadd allows to add entry with empty DN
by hyc＠symas.com 05 Mar '09

05 Mar '09

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > When slapd is configured to host a database with empty suffix (""), an entry > with empty DN can be slapadd'ed, but not ldapadd'ed. I believe the latter > behavior is appropriate, while the former should be denied. No, you need to be able to slapadd the context entry, in particular to restore a contextCSN. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6000) slapadd allows to add entry with empty DN
by ando＠sys-net.it 05 Mar '09

05 Mar '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando When slapd is configured to host a database with empty suffix (""), an entry with empty DN can be slapadd'ed, but not ldapadd'ed. I believe the latter behavior is appropriate, while the former should be denied. p.

1 0

(ITS#5999) syncprov_op_mod seg. fault
by rein＠OpenLDAP.org 05 Mar '09

05 Mar '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Solaris10 URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein Seg. fault seen when running (an extended) test050. Looks to me as if the "mt" was freed and reused while syncprov_op_mod waited for it to get to the head of the list. Rein Tollevik Basefarm AS t@5 (l@5) terminated by signal SEGV (no mapping at the fault address) 0xfffffd7ffecb7534: _ceil_mylist_del+0x0024: cmpq %rdi,0x0000000000000008(%rax) Current function is ldap_pvt_thread_mutex_unlock 308 return ERRVAL( pthread_mutex_unlock( mutex ) ); (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() t@2 a l@2 slapd_daemon_task() LWP suspended in __pollsys() t@3 a l@3 ldap_int_thread_pool_wrapper() LWP suspended in __fdsync() t@4 a l@4 ldap_int_thread_pool_wrapper() sleep on 0x6d7e00 in __lwp_park() o> t@5 a l@5 ldap_int_thread_pool_wrapper() signal SIGSEGV in _ceil_mylist_del() t@6 a l@6 ldap_int_thread_pool_wrapper() sleep on 0x6d7e00 in __lwp_park() t@7 a l@7 ldap_int_thread_pool_wrapper() LWP suspended in lwp_yield() (dbx) where current thread: t@5 [1] _ceil_mylist_del(0x7efa18, 0xfffffd7ffeb52400, 0x7efa18, 0x0, 0x7efa00, 0x6d7de0), at 0xfffffd7ffecb7534 [2] mutex_unlock_internal(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffecb9da8 [3] __mutex_unlock(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffecb9fea =>[4] ldap_pvt_thread_mutex_unlock(mutex = 0x7efa18), line 308 in "thr_posix.c" [5] syncprov_op_mod(op = 0xfffffd7ffc9ff5b0, rs = 0xfffffd7ffc9ff0e8), line 1951 in "syncprov.c" [6] overlay_op_walk(op = 0xfffffd7ffc9ff5b0, rs = 0xfffffd7ffc9ff0e8, which = op_add, oi = 0x74abc0, on = 0x744980), line 659 in "backover.c" [7] over_op_func(op = 0xfffffd7ffc9ff5b0, rs = 0xfffffd7ffc9ff0e8, which = op_add), line 721 in "backover.c" [8] over_op_add(op = 0xfffffd7ffc9ff5b0, rs = 0xfffffd7ffc9ff0e8), line 767 in "backover.c" [9] syncrepl_entry(si = 0x7973b0, op = 0xfffffd7ffc9ff5b0, entry = 0x7b55b8, modlist = 0xfffffd7ffc9ff350, syncstate = 1, syncUUID = 0xfffffd7ffc9ff3f0, syncCSN = (nil)), line 2165 in "syncrepl.c" [10] do_syncrep2(op = 0xfffffd7ffc9ff5b0, si = 0x7973b0), line 892 in "syncrepl.c" [11] do_syncrepl(ctx = 0xfffffd7ffc9ffc88, arg = 0x790140), line 1345 in "syncrepl.c" [12] connection_read_thread(ctx = 0xfffffd7ffc9ffc88, argv = 0x13), line 1225 in "connection.c" [13] ldap_int_thread_pool_wrapper(xpool = 0x6d7de0), line 663 in "tpool.c" [14] _thr_setup(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffecc0bfb [15] _lwp_start(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffecc0e30 (dbx) up Current function is syncprov_op_mod 1951 ldap_pvt_thread_mutex_unlock( &mt->mt_mutex ); (dbx) print *mt *mt = { mt_mods = 0x73206c6c613d6e63 mt_tail = 0x3d756f2c66666174 mt_op = 0x642c7370756f7267 mt_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 15714U __pthread_mutex_flag2 = 'e' __pthread_mutex_ceiling = 'x' __pthread_mutex_type = 28001U __pthread_mutex_magic = 27760U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 7299901U } __pthread_mutex_owner64 = 31352836059037696U } __pthread_mutex_data = 0 } } (dbx) print (char *) mt (char *) mt = 0x7efa00 "cn=all staff,ou=groups,db=exampl"

1 0

Re: (ITS#5998) jitterbug
by michael＠stroeder.com 05 Mar '09

05 Mar '09

Kurt(a)OpenLDAP.org wrote: > On Mar 4, 2009, at 6:53 PM, hyc(a)OpenLDAP.org wrote: > >> Full_Name: Howard Chu >> Version: 1.0 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (76.91.220.157) >> Submitted by: hyc >> >> >> Where are these resubmits coming from? > > My guess: the user. Yes, it happened also to me one time. I think there was a change in the UI which makes it more easy to submit the input form twice. Ciao, Michael.

1 0

Re: (ITS#5985) replication lockout with syncrepl
by hyc＠symas.com 05 Mar '09

05 Mar '09

hyc(a)symas.com wrote: > Fixing this issue would require a complete redesign of the psearch queue > handling. Instead of queuing up a separate response per psearch, there should > be a single queue of responses, and the qplayer should iterate thru to match a > response to each of the active psearches. That would guarantee that all > replicas receive a given change before any of them receives the next change. > This would also help with the ordering issues discussed recently on -technical > and -devel. Except that this would also force all replication to run at the speed of the slowest consumer... > I suspect this is too big a change to target the next (.16) release, since > we're focusing on re-stabilizing the code right now. The new code in HEAD is actually simpler now, it just pushes ops into the thread pool. Please test... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by ando＠sys-net.it 05 Mar '09

05 Mar '09

mariusp44(a)gmail.com wrote: > sorry, if I was misunderstood. I am not asking to do my legwork. Just > trying to understand what is going wrong. Sorry, if it seemed that way. > > I installed Sun Studio 12 (latest) and the problem is the same. I don't > think Sun Studio is not working compiler. Just looks very unlikely. IT > compiles everything without single problem. both 32 and 64 bit memory > models. > > Perhaps I was not entirely clear. Weird thing is that it is only not > working when changing password using ldappasswd and hash is set to SMD5 > SSHA or CRYPT. If I manually change the password setting userPassword > after generating it with slappasswd using say SSHA, it works fine. I > mean user can bind using password that is stored in SSHA or SMD5. That > tells me that slapd can still do encryption properly and check against > hashes in question. At some point it needs to generate a hash and does > it properly. Only when slapd is asked to change a password with > ldappasswd it is unable to generate proper hash. Unless process is > entirely different when changing password and authorizing against password. > I am not insisting it is a bug in slapd code. But I am running out of > ideas what else could be wrong and was just hoping that somebody else is > using openldap on the same architecture and perhaps experienced > something similar. Since no one else is seeing the problem, I already recommended that you step in the (non-optimized) code with a debugger and see why this happens. The right place to start is slap_passwd_hash_type(), whose failure is setting the error message you see. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by mariusp44＠gmail.com 04 Mar '09

04 Mar '09

sorry, if I was misunderstood. I am not asking to do my legwork. Just trying to understand what is going wrong. Sorry, if it seemed that way. I installed Sun Studio 12 (latest) and the problem is the same. I don't think Sun Studio is not working compiler. Just looks very unlikely. IT compiles everything without single problem. both 32 and 64 bit memory models. Perhaps I was not entirely clear. Weird thing is that it is only not working when changing password using ldappasswd and hash is set to SMD5 SSHA or CRYPT. If I manually change the password setting userPassword after generating it with slappasswd using say SSHA, it works fine. I mean user can bind using password that is stored in SSHA or SMD5. That tells me that slapd can still do encryption properly and check against hashes in question. At some point it needs to generate a hash and does it properly. Only when slapd is asked to change a password with ldappasswd it is unable to generate proper hash. Unless process is entirely different when changing password and authorizing against password. I am not insisting it is a bug in slapd code. But I am running out of ideas what else could be wrong and was just hoping that somebody else is using openldap on the same architecture and perhaps experienced something similar. /M. hyc(a)symas.com wrote: > mariusp44(a)gmail.com wrote: >> as I have pointed out in earlier post not only it doesn't work when I >> compile it myself but also the one that was downloaded form >> sunfreeware.com. It is not possible to tell what version of gcc was >> used to compile openldap that is distributed but explanation that it >> doesn't work because of compiler bug seems to me highly unlikely. >> Unless you can specifically point to which bug in gcc on SPARC >> contributes to this erratic behaviour of openldap. > > It's not our responsibility to do your legwork for you. You can easily email > the maintainers at sunfreeware.com and ask them. Since they currently host gcc > 3.4.6 on their site it's a safe bet they're still using gcc 3.4.x overall. > > Fyi, I have just now built the 2.4.15 source using gcc 4.0.3 on SPARC/Solaris > and all of the hash mechanisms work fine. I don't have a gcc 3.x build handy > on my system, nor do I see any reason to install a known-bad compiler just to > further demonstrate what has already been plainly documented by other folks. >> Either way, thanks for comments. >> >> /M. >> >> On Mon, Mar 2, 2009 at 5:56 PM,<hyc(a)symas.com> wrote: >>> ando(a)sys-net.it wrote: >>>> mariusp44(a)gmail.com wrote: >>>>> I have just compiled and tested 2.4.15 and result is same: cleartext, >>>>> md5 and sha works, smd5, ssha and crypt doesn't. >>>>> >>>>> Solaris 10 SPARC latest, gcc 3.4.3, Berkeley DB 4.7.25, opessl 0.9.8j. >>>> I have no chance to test on that arch. You should figure our why those >>>> hashes are not supported. Did you enable crypt (--enable-crypt)? >>> gcc 3.4.3 was released November 4 2004 http://gcc.gnu.org/gcc-3.4/ >>> >>> and is known to have many bugs. It's also already known that old gcc releases >>> have other problems on Sparc. (E.g. ITS#5875.) >>> >>> Please use a working compiler. >>> >>> As a workaround, recompile the offending functions with optimization disabled. >>> That usually helps in cases like this. >>> >>> There is no bug in OpenLDAP Software here, this ITS will be closed. >>> >>> -- >>> -- Howard Chu >>> CTO, Symas Corp. http://www.symas.com >>> Director, Highland Sun http://highlandsun.com/hyc/ >>> Chief Architect, OpenLDAP http://www.openldap.org/project/ >>> >>> >>> >> >> > >

1 0

Re: (ITS#5991) slapd+gnutls doesn't send all of the CA certs available in the certficate chain while slapd+openssl does
by hyc＠symas.com 04 Mar '09

04 Mar '09

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> mathias.gug(a)canonical.com wrote: >>> 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) >>> >>> >>> slapd+gnutls doesn't send all the certificates in the chain while slapd+openssl >>> does. >>> >>> openldap version: 2.4.15 >>> gnutls version: 2.4.2 >>> openssl version: 0.9.8g > > I'm unable to reproduce this using GnuTLS 2.6. Why are you using 2.4? > Hm, I may have been testing the wrong code before, I see it now. A fix is coming in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5991) slapd+gnutls doesn't send all of the CA certs available in the certficate chain while slapd+openssl does
by hyc＠symas.com 04 Mar '09

04 Mar '09

hyc(a)symas.com wrote: > mathias.gug(a)canonical.com wrote: >> 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) >> >> >> slapd+gnutls doesn't send all the certificates in the chain while slapd+openssl >> does. >> >> openldap version: 2.4.15 >> gnutls version: 2.4.2 >> openssl version: 0.9.8g I'm unable to reproduce this using GnuTLS 2.6. Why are you using 2.4? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5991) slapd+gnutls doesn't send all of the CA certs available in the certficate chain while slapd+openssl does
by hyc＠symas.com 04 Mar '09

04 Mar '09

mathias.gug(a)canonical.com wrote: > 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) > > > slapd+gnutls doesn't send all the certificates in the chain while slapd+openssl > does. > > openldap version: 2.4.15 > gnutls version: 2.4.2 > openssl version: 0.9.8g > > Here are two systems running slapd 2.4.15 - one compiled with gnutls > (t-slapd-gnutls), the other with openssl (t-slapd-openssl). This appears to be a logical disconnect between the GnuTLS and OpenSSL APIs; the OpenLDAP docs were written for OpenSSL... The way we use the OpenSSL library, it's assumed that only a single cert and key are present in the configured certfile and keyfile, and all of the relevant CAs for that cert are present in the CA file/path. In the GnuTLS library, the library expects the entire cert chain to be present in the certfile. I think it's clear from this message http://groups.google.com/group/linux.debian.bugs.dist/msg/8fec96a62571d6e9 that this is a weakness in the GnuTLS API, one that prevents it from distinguishing between CA certs and end-entity certs, and thus the reason the whole V1 trust problem arose in the first place. As an immediate workaround, you can simply copy the appropriate CA certs into your server cert file. In the meantime it looks like we'll just have to use gnutls_certificate_set_x509_key() to address this. > mathiaz@t-slapd-gnutls:~$ gnutls-cli --x509cafile allca.pem --print-cert -p 636 > t-slapd-gnutls. > Processed 2 CA certificate(s). > Resolving 't-slapd-gnutls.'... > Connecting to '172.19.42.87:636'... > - Certificate type: X.509 > - Got a certificate list of 1 certificates. > > - Certificate[0] info: > > -----BEGIN CERTIFICATE----- > MIICyTCCAjKgAwIBAgIBBTANBgkqhkiG9w0BAQUFADBIMQswCQYDVQQGEwJDQTEL > MAkGA1UECBMCUUMxEDAOBgNVBAoTB01hdGhpYXoxGjAYBgNVBAMTEVRFU1QgQ0FW > MSAtIEhBUkRZMB4XDTA5MDMwNDE5NTcxMVoXDTEwMDMwNDE5NTcxMVowRjELMAkG > A1UEBhMCQ0ExCzAJBgNVBAgTAlFDMRAwDgYDVQQKEwdNYXRoaWF6MRgwFgYDVQQD > Ew90LXNsYXBkLWdudXRscy4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL5X > ERAGYnqTCJae2FnEB1qT2Hk0sNiD1n+mnyhNDespomTINPLKpZZmqOSlD7x71zuy > DQ/Z6uxgIxOhuUV9VVo2cISi9MmEOYn4qxGq2YIHyra5FJZf6O43qajicDaRRzGz > UA17ap7vDqgig9T4qFvwCllz4EFlcTzxV+N99m1RAgMBAAGjgcQwgcEwCQYDVR0T > BAIwADALBgNVHQ8EBAMCBaAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJh > dGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBSii4L1Po9xGWrMD2oG8VeFuTQtfzBa > BgNVHSMEUzBRoUykSjBIMQswCQYDVQQGEwJDQTELMAkGA1UECBMCUUMxEDAOBgNV > BAoTB01hdGhpYXoxGjAYBgNVBAMTEVRFU1QgQ0FWMSAtIEhBUkRZggEAMA0GCSqG > SIb3DQEBBQUAA4GBAEEQMsEc0VQOt1y8B22xfRewUmwMKk34J80aFkKuG/RQJoBw > TSnlHpqyZFvmOu4JaCJAh6IdTdxfsuDB5vu/5kpNMc3jJX1Ale17l1MuxB6lvcKn > zG3A17BIIZh3aoJcVQgDAQ8Vr/I9z8y51i1Qr37E5HF2GjuuyF+5BJz9lITq > -----END CERTIFICATE----- > > # The hostname in the certificate matches 't-slapd-gnutls.'. > # valid since: Wed Mar 4 14:57:11 EST 2009 > # expires at: Thu Mar 4 14:57:11 EST 2010 > # fingerprint: 72:5A:24:83:6C:5C:3F:0E:80:52:F1:61:CD:C3:0D:31 > # Subject's DN: C=CA,ST=QC,O=Mathiaz,CN=t-slapd-gnutls. > # Issuer's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY > > > - Peer's certificate is trusted > - Version: TLS1.1 > - Key Exchange: RSA > - Cipher: AES-128-CBC > - MAC: SHA1 > - Compression: NULL > - Handshake was completed > > - Simple Client Mode: > > mathiaz@t-slapd-gnutls:~$ gnutls-cli --x509cafile allca.pem --print-cert -p 636 > t-slapd-openssl. > Processed 2 CA certificate(s). > Resolving 't-slapd-openssl.'... > Connecting to '172.19.42.220:636'... > - Certificate type: X.509 > - Got a certificate list of 2 certificates. > > - Certificate[0] info: > > -----BEGIN CERTIFICATE----- > MIIB/jCCAWcCAQcwDQYJKoZIhvcNAQEFBQAwSDELMAkGA1UEBhMCQ0ExCzAJBgNV > BAgTAlFDMRAwDgYDVQQKEwdNYXRoaWF6MRowGAYDVQQDExFURVNUIENBVjEgLSBI > QVJEWTAeFw0wOTAzMDQyMDExMTRaFw0xMDAzMDQyMDExMTRaMEcxCzAJBgNVBAYT > AkNBMQswCQYDVQQIEwJRQzEQMA4GA1UEChMHTWF0aGlhejEZMBcGA1UEAxMQdC1z > bGFwZC1vcGVuc3NsLjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzTEuHfVR > ELoXxSyVTwWrfIIsoKqBfbZYJSGQcTTEtuvxABxX8AoKyc9T+AkhR4wsSmRZGOBz > opH9u0LReaGyhWkUA/XaFF24jkSogi6yDsh478P/ayZjushPLh9LpIeW/2lD9xkh > t5LGW255lXIMGI5+/x8EgiaU1pS5OO9wz/kCAwEAATANBgkqhkiG9w0BAQUFAAOB > gQBlg/lIawsDYFqqNz61BNl2nix4LrIRFxiOA/p14VFkRyuCVHXDjhBtlb13wBZk > wVTDfUdykvy2nlJq8bLQ7OYYdiA4h64HMnLTMyMALKBFiVwyrg/GvF7TsUg3K41K > uFTF0H1bQOmqrJPcIu8r+h3gQLkCRvBLssZaQtA4M4jw4A== > -----END CERTIFICATE----- > > # The hostname in the certificate matches 't-slapd-openssl.'. > # valid since: Wed Mar 4 15:11:14 EST 2009 > # expires at: Thu Mar 4 15:11:14 EST 2010 > # fingerprint: 85:7F:06:0A:EC:3A:9E:6C:78:BC:FC:C3:8F:4D:4B:E9 > # Subject's DN: C=CA,ST=QC,O=Mathiaz,CN=t-slapd-openssl. > # Issuer's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY > > - Certificate[1] info: > > -----BEGIN CERTIFICATE----- > MIIB/zCCAWgCAQAwDQYJKoZIhvcNAQEFBQAwSDELMAkGA1UEBhMCQ0ExCzAJBgNV > BAgTAlFDMRAwDgYDVQQKEwdNYXRoaWF6MRowGAYDVQQDExFURVNUIENBVjEgLSBI > QVJEWTAeFw0wOTAzMDMxODI1NTBaFw0xMjAzMDIxODI1NTBaMEgxCzAJBgNVBAYT > AkNBMQswCQYDVQQIEwJRQzEQMA4GA1UEChMHTWF0aGlhejEaMBgGA1UEAxMRVEVT > VCBDQVYxIC0gSEFSRFkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMZSKqDg > Y5rn4SgJUgnO0IAM2Us/5sQ18mu8gxoDeLkIcHHuiwYHeT4BcOit2hemmOCIEolh > XPKkMD4MVAbafDFtJjhuEgPtWoUuZcOa9gRi3eH+h7QEYhhwnwLewrQGhx4tsfY4 > wR3LIUm/lxkJISy17v3uc5yNLcAlreUrrdJ1AgMBAAEwDQYJKoZIhvcNAQEFBQAD > gYEAAsaBDAMUKofwOZPNNV/9EKglG7O3G5p/i9h8n5C3bXy6E6vWtVxqpWd5qBEt > uMXU1vIIop7FrKornuPWtEy4jKSw12Sv9EXaUJ9rfXQTWh6GpgUmTjlZtOwjABT9 > fAU4M9MdLDTBaZA11NqtdMMPKTwTHXjmv9bKcgOLh1g5WhQ= > -----END CERTIFICATE----- > > # valid since: Tue Mar 3 13:25:50 EST 2009 > # expires at: Fri Mar 2 13:25:50 EST 2012 > # fingerprint: 66:D2:B7:8E:03:DD:BF:24:4D:A1:D8:EA:8E:6F:8B:80 > # Subject's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY > # Issuer's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY > > > - Peer's certificate is trusted > - Version: TLS1.0 > - Key Exchange: RSA > - Cipher: AES-128-CBC > - MAC: SHA1 > - Compression: NULL > - Handshake was completed > > - Simple Client Mode: > > ^C > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5998) jitterbug
by Kurt＠OpenLDAP.org 04 Mar '09

04 Mar '09

On Mar 4, 2009, at 6:53 PM, hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: 1.0 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > Where are these resubmits coming from? My guess: the user. -- Kurt

1 0

Re: (ITS#5992) libldap with gnutls don't trust V1 CAs.
by hyc＠symas.com 04 Mar '09

04 Mar '09

mathias.gug(a)canonical.com wrote: > 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? Just to be clear, are you requesting that libldap unconditionally call gnutls_certificate_set_verify_flags() with GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT parameter? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5998) jitterbug
by hyc＠OpenLDAP.org 04 Mar '09

04 Mar '09

Full_Name: Howard Chu Version: 1.0 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Where are these resubmits coming from?

1 0

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs