[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Tools for tracing TLS/SSL
Tony,
I tried the DNS lookup:
# nslookup aptrain.comneti.com
Using /etc/hosts on: aptrain
looking up FILES
Name: aptrain.comneti.com
Address: 56.0.0.15
# nslookup 56.0.0.15
Using /etc/hosts on: aptrain
looking up FILES
Name: aptrain.comneti.com
Address: 56.0.0.15
Looks it is working. Was ethereal useful for resolving your problems ?
thanks,
dinesh
Tony Earnshaw wrote:
> 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
>
> ------------------------------------------------------------------------
> Name: signature.asc
> signature.asc Type: application/pgp-signature
> Description: Dette er en digitalt signert meldingsdel