openldap-bugs March 2009

openldap-bugs@openldap.org

48 participants
245 discussions

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

← Newer
1
...
16
17
18
19
20
21
22
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2009