openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

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 05 Mar '09

05 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 05 Mar '09

05 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 05 Mar '09

05 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 05 Mar '09

05 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs