From: Xeno Campanoli <xeno.campanoli@...>
Date: 2009-06-02T05:30:49+09:00
Subject: Re: Something Not going with my LDAP using SSL

Xeno Campanoli wrote:
Okay, here we go Brian,

SSL-Session:
     Protocol  : TLSv1
     Cipher    : RC4-MD5
     Session-ID: 46AECE8C1C97B9CE8D0547CD2FFF0DB787B11E90A2E4387A430CBEB3996BA67C
     Session-ID-ctx:
     Master-Key: 
57B5AD4C296C9B0987539FB728F6ADBC7C6A9C579F0E119E87F7B621769D738053220479ADBA5E811EB163E273D5034E
     Key-Arg   : None
     Start Time: 1243888048
     Timeout   : 300 (sec)
     Verify return code: 0 (ok)

is what I get when I add the -CAfile $certpath

to the command you gave.  So, as you can see, we get the proper response when we 
specify the right cert.  But when we do not, it whines.  I believe the app is 
doing the same thing as the first openssl command did that gave the 19 result 
code, and that we somehow need to specify location of the cert just like we do 
with openssl and the -CAfile switch.  Am strongly interested in your reaction to 
this guess on my part.

Sincerely, Xeno

> Xeno Campanoli wrote:
>> Brian Candler wrote:
>>> Xeno Campanoli wrote:
>>>> 11:11:51.716923 IP 192.168.141.130.44841 > 192.168.139.157.636: R
>>>> 3432003446:3432003446(0) win 0
>>>>   0x0000:  4500 0028 0000 4000 4006 a05f c0a8 8d82  E..(..@.@.._....
>>>>   0x0010:  c0a8 8b9d af29 027c cc90 3776 0000 0000  .....).|..7v....
>>>>   0x0020:  5004 0000 5fc3 0000                      P..._...
>>>
>>> Odd, I think this shows it was the client (on dynamic port 44841) 
>>> which closes the connection by sending a RST to the server. But why 
>>> not a normal FIN?
>>>
>>> I suspect this is not a certificate problem - a lot of negotiation 
>>> has taken place since the server sent its certificate - but I cannot 
>>> be sure of that.
>>>
>>> What about openssl s_client -connect 192.168.139.157:636 ? What does 
>>> that show?
>>>
>> STDOUT ends with the following...
>>
>> SSL-Session:
>>     Protocol  : TLSv1
>>     Cipher    : RC4-MD5
>>     Session-ID: 
>> 46AEE896A3CB7B0C0044D1169EA9672E769D7BF64194F96D8378D08D750D60AA
>>     Session-ID-ctx:
>>     Master-Key: 
>> FEADCD684F8CCEEA674C2D725D6BB5E4C1716B877C2B6B176E1C5BD0590D0CDFA28CC93BEB07548C997BD6B2FAB7009F 
>>
>>     Key-Arg   : None
>>     Start Time: 1243885042
>>     Timeout   : 300 (sec)
>>     Verify return code: 19 (self signed certificate in certificate chain)
>>
>>
> I think we had a different response Friday.  Is it possible that install 
> of libopenssl-ruby has changed the cert location?
>