tor, 2002-09-05 kl. 00:17 skrev Dinesh Salegame: Look for comments below this "hunk"! ---------------------------- > client > ----- > ----------snip----------------- > TLS certificate verification: depth: 1, err: 0, subject: /C=US/ST=ILLINOIS/L=Lis > leCA/O=Comnet Int/OU=CA/CN=aptrain.comneti.com/Email=dvs@comneti.com, issuer: /C > =US/ST=ILLINOIS/L=LisleCA/O=Comnet Int/OU=CA/CN=aptrain.comneti.com/Email=dvs@co > mneti.com > TLS certificate verification: depth: 0, err: 0, subject: /C=US/ST=ILLINOIS/O=Com > net Int/OU=CE/CN=aptrain.comneti.com/Email=dvs@comneti.com, issuer: /C=US/ST=ILL > INOIS/L=LisleCA/O=Comnet Int/OU=CA/CN=aptrain.comneti.com/Email=dvs@comneti.com > TLS trace: SSL_connect:SSLv3 read server certificate A > tls_read: want=5, got=5 > 0000: 16 03 01 00 04 ..... > tls_read: want=4, got=4 > 0000: 0e 00 00 00 .... > TLS trace: SSL_connect:SSLv3 read server done A > TLS trace: SSL_connect:SSLv3 write client key exchange A > TLS trace: SSL_connect:SSLv3 write change cipher spec A > TLS trace: SSL_connect:SSLv3 write finished A > tls_write: want=190, written=190 > 0000: 16 03 01 00 86 10 00 00 82 00 80 71 48 4d 7e fb ...........qHM~. > 0010: b4 e7 08 b5 62 6e 57 fd 6a 9b 3b 00 e8 fc 8b f8 ....bnW.j.;..... > 0020: 15 c6 bd 83 55 9a a4 28 c8 91 7e 58 1d f7 2d ef ....U..(..~X..-. > 0030: 53 61 e4 d5 70 a7 bb 24 17 5b e0 9d 6e fd 8d b1 Sa..p..$.[..n... > 0040: 32 fd 8a 05 0d 05 97 bc e6 10 ee e9 86 69 c5 13 2............i.. > 0050: 97 af d4 b3 a6 0a 07 47 f3 6a a0 7a e7 67 b3 c6 .......G.j.z.g.. > 0060: d9 4c 05 87 30 cc 3c 4b 53 b9 13 29 f7 91 7c c7 .L..0.<KS..)..|. > 0070: e4 b3 f4 74 9e 32 49 18 da 22 06 b3 d5 ad 14 0d ...t.2I.."...... > 0080: 4d a2 d6 c8 2f 6a a5 48 b5 1c 82 14 03 01 00 01 M.../j.H........ > 0090: 01 16 03 01 00 28 25 b7 85 ad 9a 5a ab 0a 2f e3 .....(%....Z../. > 00a0: 1c 47 eb da a6 27 94 7d 5c 8b 6c b1 6a 61 cb 7f .G...'.}\.l.ja.. > 00b0: d2 41 8f 5a 86 2d c1 8f 6b a4 da 77 f6 ca .A.Z.-..k..w.. > TLS trace: SSL_connect:SSLv3 flush data ----------------------- This is very interesting. I didn't know I could run ldapsearch with a '-d -1' option, but now I do. Had I realized this, it would have saved me hours of work and cut out the need for Ethereal and strace completely. I ran ldapsearch with my own ldaps bind, which works well for me, and in fact I use it for smtp aliases, auth and a lot else in practice. What *you* get is this (more comments below the "hunk"): ------------------------ > TLS trace: SSL_connect:SSLv3 read server certificate A > tls_read: want=5 error=Connection reset by peer > TLS trace: SSL_connect:error in SSLv3 read finished A > TLS trace: SSL_connect:error in SSLv3 read finished A > TLS: can't connect. > ldap_perror > ldap_start_tls: Connect error (91) ------------------------- What *I* get, at this point, it this: ------------------------- TLS trace: SSL_connect:SSLv3 read server certificate A tls_read: want=5, got=5 0000: 16 03 01 00 04 ..... tls_read: want=4, got=4 0000: 0e 00 00 00 .... TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A tls_write: want=190, written=190 _______________________ Then my debug goes on to give the desired result. So, the question is: "Why?" I have had a terrible time in getting my (only) test machine to recognize the FQDN of the machine on which it's running. In spite of the advice given on this list. This is because it's sometimes a standalone machine and sometimes connected to the Internet with a different FQDN/IP number. Your certificate is granted/signed for "CN=aptrain.comneti.com". Are you absolutely sure that you can do a succesful DNS lookup of aptrain.comneti.com and get a valid IP number, then do a reverse lookup of that IP number and resolve it back to aptrain.comneti.com? That's what messed things up for me, for a long time, and even stops me implementing Kerberos. (B.T.W. I *know* I can implement workarounds for this, and even got them working, but that messes up so many applications, that it's just not worth the hassle). Best, Tony -- Tony Earnshaw The usefulness of RTFM is vastly overrated. e-post: tonni@billy.demon.nl www: http://www.billy.demon.nl gpg public key: http://www.billy.demon.nl/tonni.armor Telefoon: (+31) (0)172 530428 Mobiel: (+31) (0)6 51153356 GPG Fingerprint = 3924 6BF8 A755 DE1A 4AD6 FA2B F7D7 6051 3BE7 B981 3BE7B981
Attachment:
signature.asc
Description: Dette er en digitalt signert meldingsdel