Something Not going with my LDAP using SSL

I have the following working with cleartext LDAP:

#!/usr/bin/ruby

require ‘ldap’

begin
ldap_host = ‘myldaphost’
ldap_port = 389
ldap_conn = LDAP::Conn.new(ldap_host,ldap_port)
puts “trace 2 ldap_conn: #{ldap_conn.class}”

ldap_conn.set_option( LDAP::LDAP_OPT_PROTOCOL_VERSION, 3 )

 puts "trace 3 ldap_conn:  #{ldap_conn.class}"
 bind_dn = "uid=#{ARGV[0]},ou=People,ou=Corporate,dc=x,dc=com"
 password_dn = "#{ARGV[1]}"
 ldap_conn.bind(bind_dn,password_dn)
 puts "trace 4 ldap_conn:  #{ldap_conn.class}"

rescue
puts “trace 5 oops”
end

end of test

----snip—

But when I try to run it with SSL, I get a failure saying “Can’t connect
LDAP
Server”. My admin says it is not seeing the certificate. I need to
either
accept the certificate or turn certification off, but for the life of me
I am
looking at the rdoc and I cannot find methods for either. Perhaps I
just don’t
understand the vocabulary or something, but I would expect this to be
simple.
My SSL version is as follows, and gets the diagnosic I gave above:
#!/usr/bin/ruby

require ‘ldap’

begin
ldap_host = ‘myldaphost’
ldap_port = 636
ldap_conn = LDAP::SSLConn.new(ldap_host,ldap_port)
puts “trace 2 ldap_conn: #{ldap_conn.class}”
ldap_conn.set_option( LDAP::LDAP_OPT_PROTOCOL_VERSION, 3 )
puts “trace 3 ldap_conn: #{ldap_conn.class}”
bind_dn = “uid=#{ARGV[0]},ou=People,ou=Corporate,dc=x,dc=com”
password_dn = “#{ARGV[1]}”
ldap_conn.bind(bind_dn,password_dn)
puts “trace 4 ldap_conn: #{ldap_conn.class}”
rescue
puts “trace 5 oops, #{$!}”
end

end of test

----snip—
Here is the output:
u@h:$ ./t7.rb un ‘pw’
trace 2 ldap_conn: LDAP::SSLConn
trace 3 ldap_conn: LDAP::SSLConn
trace 5 oops, Can’t contact LDAP server
u@h:$

On the first one, with the proper u/p I get the trace 4. Anyway, please
can
someone suggest what I may be leaving out, or what is the method for
specifying
certs or no certs, both would be nice.

Thanks ahead of time.

Sincerely, Xeno

Xeno C. wrote:

But when I try to run it with SSL, I get a failure saying “Can’t connect
LDAP
Server”.

It looks like you are trying to connect to the LDAPS service on port
636. Are you sure your server implements this? Try:

telnet myldaphost 636

Do you get connection accepted, or rejected?

If it is accepted, then try

openssl s_client -connect myldaphost:636

Is SSL successfully negotiated?

The reason I ask is because there is another, completely different way
of doing LDAP with SSL (using the STARTTLS extension on port 389). Maybe
this is what your server implements instead.

Brian C. wrote:

Xeno C. wrote:

But when I try to run it with SSL, I get a failure saying “Can’t connect
LDAP
Server”.

My apologies for dropping this before Brian. I just found it in my
trash, so I
must have knocked it when I was in a hurry. I always appreciate attempts
to
help, and you were right that I had not yet installed the
libopenssl-ruby
package in my ubuntu.

However, I just did install it, and so far to no avail. I am rebooting,
and…
after logging in I still get the same problem where I never get to trace
4, but
instead have:

trace 5 oops, Can’t contact LDAP server

As to your comment below, I really appreciate that too. However, the
script I
describe works on other machines, most specifically CentOS and RedHat5,
and a
RedHat4 I think, with the same port numbers and other specifications, so
the
main difference appears to be the way the Ruby stuff is installed on
Ubuntu. On
fellow who was assisting me was also able to do openssl tool checks on
my system
that showed he could do all the proper functions at that level, so we
are
apparently left with some combination of Ubuntu and Ruby and OpenSSL
that is not
functioning properly. That doesn’t mean I haven’t done something
stupid, but I
did install a 9.04 OS just to test this problem, and I tried to step
though
everything I could think of both methodically and minimally and we just
don’t
get it to go on either that system, or the production 8.04 system. I
will be
able to work on this problem at intervals for the next couple of days
because of
the potential value of this, so of you can instruct me on other things
to try I
will try to get them done with fast turnaround.

My apologies if I have left any other item off which should be obvious,
and
thank you once again for all your energies.

Sincerely, Xeno

Xeno C. wrote:

However, the
script I
describe works on other machines, most specifically CentOS and RedHat5,
and a
RedHat4 I think, with the same port numbers and other specifications, so
the
main difference appears to be the way the Ruby stuff is installed on
Ubuntu.

Maybe. Or perhaps the Ubuntu box’s IP address is being firewalled, or
something strange like that. So please start by doing the telnet and
s_client tests I posted, and showing the results.

Since you have an A/B comparison you can do between two installations,
please also do this as root on both boxes:

tcpdump -i eth0 -s0 -n -X tcp port 636

Then run the script on both boxes, and compare the output. (If it’s
actually establishing an encrypted SSL session then it will look like
garbage, but I suspect that the connection is being rejected in one
case, since that’s what the error message says)

Can you tell me more specifically what I might be looking for? I don’t
want to
splatter too much around and I feel a little lost here…?

Sincerely, Xeno

out, which appears normal.
0x0010: c0a8 8b9d af29 027c cc90 3655 0000 0000 …).|…6U…
0x0020: a002 16d0 8f35 0000 0204 05b4 0402 080a …5…
0x0030: 0004 52fb 0000 0000 0103 0306 …R…
11:11:51.693644 IP 192.168.139.157.636 > 192.168.141.130.44841: S
3906532269:3906532269(0) ack 3432003158 win 5792 <mss
…snip…

Brian C. wrote:

Maybe. Or perhaps the Ubuntu box’s IP address is being firewalled, or
something strange like that. So please start by doing the telnet and
s_client tests I posted, and showing the results.

Since you have an A/B comparison you can do between two installations,
please also do this as root on both boxes:

tcpdump -i eth0 -s0 -n -X tcp port 636

Sorry. Going too fast again. Here:

telnet ihn 636
Trying iipaddress…
Connected to ihn.
Escape character is ‘^]’.
—snip—
Had to hack out the real hostname of course but that is how it comes
out, which
appears normal.

the other ones I have:

~# tcpdump -i eth0 -s0 -n -X tcp port 636
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:11:51.693153 IP 192.168.141.130.44841 > 192.168.139.157.636: S
3432003157:3432003157(0) win 5840 <mss 1460,sackOK,timestamp 283387
0,nop,wscale 6>
0x0000: 4500 003c 64ae 4000 4006 3b9d c0a8 8d82 E…<d.@.@.;…
0x0010: c0a8 8b9d af29 027c cc90 3655 0000 0000 …).|…6U…
0x0020: a002 16d0 8f35 0000 0204 05b4 0402 080a …5…
0x0030: 0004 52fb 0000 0000 0103 0306 …R…
11:11:51.693644 IP 192.168.139.157.636 > 192.168.141.130.44841: S
3906532269:3906532269(0) ack 3432003158 win 5792 <mss
1460,sackOK,timestamp
966516201 283387,nop,wscale 0>
0x0000: 4500 003c 0000 4000 3f06 a14b c0a8 8b9d E…<…@.?..K…
0x0010: c0a8 8d82 027c af29 e8d8 f3ad cc90 3656 …|.)…6V
0x0020: a012 16a0 9b4e 0000 0204 05b4 0402 080a …N…
0x0030: 399b dde9 0004 52fb 0103 0300 9…R…
11:11:51.693675 IP 192.168.141.130.44841 > 192.168.139.157.636: . ack 1
win 92
<nop,nop,timestamp 283387 966516201>
0x0000: 4500 0034 64af 4000 4006 3ba4 c0a8 8d82 E…4d.@.@.;…
0x0010: c0a8 8b9d af29 027c cc90 3656 e8d8 f3ae …).|…6V…
0x0020: 8010 005c e057 0000 0101 080a 0004 52fb ….W…R.
0x0030: 399b dde9 9…
11:11:51.699216 IP 192.168.141.130.44841 > 192.168.139.157.636: P
1:94(93) ack 1
win 92 <nop,nop,timestamp 283388 966516201>
0x0000: 4500 0091 64b0 4000 4006 3b46 c0a8 8d82 E…d.@.@.;F…
0x0010: c0a8 8b9d af29 027c cc90 3656 e8d8 f3ae …).|…6V…
0x0020: 8018 005c 9af4 0000 0101 080a 0004 52fc ….…R.
0x0030: 399b dde9 1603 0200 5801 0000 5403 024a 9…X…T…J
0x0040: 2419 e764 3471 1bc4 7dd2 4369 d785 9644 $…d4q…}.Ci…D
0x0050: a509 1f83 43b9 a8d2 193f 2754 c73c b100 …C…?‘T.<…
0x0060: 0024 0033 0045 0039 0088 0016 0032 0044 .$.3.E.9…2.D
0x0070: 0038 0087 0013 0066 002f 0041 0035 0084 .8…f./.A.5…
0x0080: 000a 0005 0004 0100 0007 0009 0003 0200 …
0x0090: 01 .
11:11:51.699639 IP 192.168.139.157.636 > 192.168.141.130.44841: . ack 94
win
5792 <nop,nop,timestamp 966516201 283388>
0x0000: 4500 0034 2e47 4000 3f06 730c c0a8 8b9d E…4.G@.?.s…
0x0010: c0a8 8d82 027c af29 e8d8 f3ae cc90 36b3 …|.)…6.
0x0020: 8010 16a0 c9b5 0000 0101 080a 399b dde9 …9…
0x0030: 0004 52fc …R.
11:11:51.700888 IP 192.168.139.157.636 > 192.168.141.130.44841: .
1:1449(1448)
ack 94 win 5792 <nop,nop,timestamp 966516201 283388>
0x0000: 4500 05dc 2e48 4000 3f06 6d63 c0a8 8b9d E…H@.?.mc…
0x0010: c0a8 8d82 027c af29 e8d8 f3ae cc90 36b3 …|.)…6.
0x0020: 8010 16a0 0b69 0000 0101 080a 399b dde9 …i…9…
0x0030: 0004 52fc 1603 0108 5a02 0000 4603 0100 …R…Z…F…
0x0040: 2832 7aaf 8965 b430 485e dd69 d8e4 bc05 (2z…e.0H^.i…
0x0050: 9d03 389e 7e8b 5dfc bef1 3777 334f be20 …8.~.]…7w3O…
0x0060: 46ae 6e15 8e3c 2a26 ffde 5c1b 793a d501 F.n…<&….y:…
0x0070: f605 d251 cf50 4da7 5dba bdea ed7e 30d8 …Q.PM.]…~0.
0x0080: 0004 000b 0007 6100 075e 0003 b030 8203 …a…^…0…
0x0090: ac30 8203 15a0 0302 0102 0201 3f30 0d06 .0…?0…
0x00a0: 092a 8648 86f7 0d01 0104 0500 3081 9931 .
.H…0…1
0x00b0: 0b30 0906 0355 0406 1302 5553 3113 3011 .0…U…US1.0.
0x00c0: 0603 5504 0813 0a57 6173 6869 6e67 746f …U…Washingto
0x00d0: 6e31 1030 0e06 0355 0407 1307 5365 6174 n1.0…U…Seat
0x00e0: 746c 6531 1b30 1906 0355 040a 1312 5265 tle1.0…U…Re
0x00f0: 616c 4e65 7477 6f72 6b73 2c20 496e 632e alNetworks,.Inc.
0x0100: 310b 3009 0603 5504 0b13 0249 5431 1830 1.0…U…IT1.0
0x0110: 1606 0355 0403 130f 5265 616c 4e65 7477 …U…RealNetw
0x0120: 6f72 6b73 2049 5431 1f30 1d06 092a 8648 orks.IT1.0….H
0x0130: 86f7 0d01 0901 1610 6d69 732d 6f70 7340 …mis-ops@
0x0140: 7265 616c 2e63 6f6d 301e 170d 3037 3038 real.com0…0708
0x0150: 3230 3030 3134 3033 5a17 0d31 3030 3831 20001403Z…10081
0x0160: 3930 3031 3430 335a 3075 310b 3009 0603 9001403Z0u1.0…
0x0170: 5504 0613 0255 5331 1330 1106 0355 0408 U…US1.0…U…
0x0180: 130a 5761 7368 696e 6774 6f6e 3110 300e …Washington1.0.
0x0190: 0603 5504 0713 0753 6561 7474 6c65 3115 …U…Seattle1.
0x01a0: 3013 0603 5504 0a13 0c52 6561 6c4e 6574 0…U…RealNet
0x01b0: 776f 726b 7331 0b30 0906 0355 040b 1302 works1.0…U…
0x01c0: 4954 311b 3019 0603 5504 0313 126c 6461 IT1.0…U…lda
0x01d0: 702d 636f 7270 2e72 6561 6c2e 636f 6d30 p-corp.real.com0
0x01e0: 819f 300d 0609 2a86 4886 f70d 0101 0105 …0…
.H…
0x01f0: 0003 818d 0030 8189 0281 8100 e5f5 cb9b …0…
0x0200: ed99 0484 e912 32c0 32a9 110b ac3e 4cc3 …2.2…>L.
0x0210: ac17 e21f 698e d0cb fa0e 734c e356 e5eb …i…sL.V…
0x0220: 1637 ec9c 0458 f16b e9b3 4c2b f65b 6a0d .7…X.k…L+.[j.
0x0230: 1245 8841 d175 c9f1 617f 4db6 72e7 482b .E.A.u…a.M.r.H+
0x0240: ef90 5b31 505c 74e0 ce17 74eb 3d8f 5bd4 …[1P\t…t.=.[.
0x0250: 06b6 77b8 5f37 a4ce abb5 acad dfc0 2628 …w.7…&(
0x0260: e03e 27a1 e4c2 8f86 5d67 3e35 8661 1b10 .>'…]g>5.a…
0x0270: d7c9 0e73 af12 964e 9ee4 7443 0203 0100 …s…N…tC…
0x0280: 01a3 8201 2530 8201 2130 0906 0355 1d13 …%0…!0…U…
0x0290: 0402 3000 302c 0609 6086 4801 86f8 4201 …0.0,…`.H…B.
0x02a0: 0d04 1f16 1d4f 7065 6e53 534c 2047 656e …OpenSSL.Gen
0x02b0: 6572 6174 6564 2043 6572 7469 6669 6361 erated.Certifica
0x02c0: 7465 301d 0603 551d 0e04 1604 1454 310b te0…U…T1.
0x02d0: 098a bca2 bfc8 6d36 5f27 ae9b a8ea f261 …m6
’…a
0x02e0: e430 81c6 0603 551d 2304 81be 3081 bb80 .0…U.#…0…
0x02f0: 1461 b6bd d7fa 2207 535c 8b83 af17 8c0c .a…“.S.…
0x0300: 123e 9baa 1da1 819f a481 9c30 8199 310b .>…0…1.
0x0310: 3009 0603 5504 0613 0255 5331 1330 1106 0…U…US1.0…
0x0320: 0355 0408 130a 5761 7368 696e 6774 6f6e .U…Washington
0x0330: 3110 300e 0603 5504 0713 0753 6561 7474 1.0…U…Seatt
0x0340: 6c65 311b 3019 0603 5504 0a13 1252 6561 le1.0…U…Rea
0x0350: 6c4e 6574 776f 726b 732c 2049 6e63 2e31 lNetworks,.Inc.1
0x0360: 0b30 0906 0355 040b 1302 4954 3118 3016 .0…U…IT1.0.
0x0370: 0603 5504 0313 0f52 6561 6c4e 6574 776f …U…RealNetwo
0x0380: 726b 7320 4954 311f 301d 0609 2a86 4886 rks.IT1.0….H.
0x0390: f70d 0109 0116 106d 6973 2d6f 7073 4072 …mis-ops@r
0x03a0: 6561 6c2e 636f 6d82 0100 300d 0609 2a86 eal.com…0…
.
0x03b0: 4886 f70d 0101 0405 0003 8181 0035 8745 H…5.E
0x03c0: 229b 343b 27a4 e6e0 d2f7 b71b 5752 3def “.4;'…WR=.
0x03d0: 160d 1e5e 2f59 d444 b219 4bf8 10eb baeb …^/Y.D…K…
0x03e0: 7e96 dd68 44d0 c42c 5cd0 f122 baf4 11bd ~…hD…,..”…
0x03f0: a2e7 2404 b0bf 71d9 6ac5 db40 8f58 ad4b …$…q.j…@.X.K
0x0400: a2ba 9fcb e4c3 261c 3856 9937 05ce c0aa …&.8V.7…
0x0410: d650 2175 6f76 549a 0574 9b9c 81bc 5785 .P!uovT…t…W.
0x0420: 86c9 e832 37fc a13e af13 41bf 0a78 c331 …27…>…A…x.1
0x0430: 97a6 336a 72d1 03a6 ea91 c77e e300 03a8 …3jr…~…
0x0440: 3082 03a4 3082 030d a003 0201 0202 0100 0…0…
0x0450: 300d 0609 2a86 4886 f70d 0101 0405 0030 0….H…0
0x0460: 8199 310b 3009 0603 5504 0613 0255 5331 …1.0…U…US1
0x0470: 1330 1106 0355 0408 130a 5761 7368 696e .0…U…Washin
0x0480: 6774 6f6e 3110 300e 0603 5504 0713 0753 gton1.0…U…S
0x0490: 6561 7474 6c65 311b 3019 0603 5504 0a13 eattle1.0…U…
0x04a0: 1252 6561 6c4e 6574 776f 726b 732c 2049 .RealNetworks,.I
0x04b0: 6e63 2e31 0b30 0906 0355 040b 1302 4954 nc.1.0…U…IT
0x04c0: 3118 3016 0603 5504 0313 0f52 6561 6c4e 1.0…U…RealN
0x04d0: 6574 776f 726b 7320 4954 311f 301d 0609 etworks.IT1.0…
0x04e0: 2a86 4886 f70d 0109 0116 106d 6973 2d6f .H…mis-o
0x04f0: 7073 4072 6561 6c2e 636f 6d30 1e17 0d30 [email protected]…0
0x0500: 3430 3232 3430 3132 3833 345a 170d 3134 40224012834Z…14
0x0510: 3032 3231 3031 3238 3334 5a30 8199 310b 0221012834Z0…1.
0x0520: 3009 0603 5504 0613 0255 5331 1330 1106 0…U…US1.0…
0x0530: 0355 0408 130a 5761 7368 696e 6774 6f6e .U…Washington
0x0540: 3110 300e 0603 5504 0713 0753 6561 7474 1.0…U…Seatt
0x0550: 6c65 311b 3019 0603 5504 0a13 1252 6561 le1.0…U…Rea
0x0560: 6c4e 6574 776f 726b 732c 2049 6e63 2e31 lNetworks,.Inc.1
0x0570: 0b30 0906 0355 040b 1302 4954 3118 3016 .0…U…IT1.0.
0x0580: 0603 5504 0313 0f52 6561 6c4e 6574 776f …U…RealNetwo
0x0590: 726b 7320 4954 311f 301d 0609 2a86 4886 rks.IT1.0…
.H.
0x05a0: f70d 0109 0116 106d 6973 2d6f 7073 4072 …mis-ops@r
0x05b0: 6561 6c2e 636f 6d30 819f 300d 0609 2a86 eal.com0…0…
.
0x05c0: 4886 f70d 0101 0105 0003 818d 0030 8189 H…0…
0x05d0: 0281 8100 d31d 2923 0962 b872 …)#.b.r
11:11:51.700893 IP 192.168.139.157.636 > 192.168.141.130.44841: P
1449:2144(695)
ack 94 win 5792 <nop,nop,timestamp 966516201 283388>
0x0000: 4500 02eb 2e49 4000 3f06 7053 c0a8 8b9d E…I@.?.pS…
0x0010: c0a8 8d82 027c af29 e8d8 f956 cc90 36b3 …|.)…V…6.
0x0020: 8018 16a0 6eba 0000 0101 080a 399b dde9 …n…9…
0x0030: 0004 52fc 427a 2beb cbfe a8e2 ff2a 31f4 …R.Bz+…1.
0x0040: 3c63 25c9 ce12 c097 040f 5c23 8a2d ceab <c%…#.-…
0x0050: d031 7599 e00a 15f2 3d61 156e cba7 f2e1 .1u…=a.n…
0x0060: e583 b3f9 556d 5f8b ed14 d516 24cf 910e …Um_…$…
0x0070: 8b6e 1204 51e4 31ec f7f2 3492 f3a6 5e82 .n…Q.1…4…^.
0x0080: 7d7d 6cd3 80a1 8a77 805b 8cb0 4f5b 3cfa }}l…w.[…O[<.
0x0090: 9596 1602 d381 4018 3f1d f939 14ac 98fa …@.?..9…
0x00a0: b53f 709b 7cf7 5783 b68f ac99 0203 0100 .?p.|.W…
0x00b0: 01a3 81f9 3081 f630 1d06 0355 1d0e 0416 …0…0…U…
0x00c0: 0414 61b6 bdd7 fa22 0753 5c8b 83af 178c …a…“.S.…
0x00d0: 0c12 3e9b aa1d 3081 c606 0355 1d23 0481 …>…0…U.#…
0x00e0: be30 81bb 8014 61b6 bdd7 fa22 0753 5c8b .0…a…”.S.
0x00f0: 83af 178c 0c12 3e9b aa1d a181 9fa4 819c …>…
0x0100: 3081 9931 0b30 0906 0355 0406 1302 5553 0…1.0…U…US
0x0110: 3113 3011 0603 5504 0813 0a57 6173 6869 1.0…U…Washi
0x0120: 6e67 746f 6e31 1030 0e06 0355 0407 1307 ngton1.0…U…
0x0130: 5365 6174 746c 6531 1b30 1906 0355 040a Seattle1.0…U…
0x0140: 1312 5265 616c 4e65 7477 6f72 6b73 2c20 …RealNetworks,.
0x0150: 496e 632e 310b 3009 0603 5504 0b13 0249 Inc.1.0…U…I
0x0160: 5431 1830 1606 0355 0403 130f 5265 616c T1.0…U…Real
0x0170: 4e65 7477 6f72 6b73 2049 5431 1f30 1d06 Networks.IT1.0…
0x0180: 092a 8648 86f7 0d01 0901 1610 6d69 732d .
.H…mis-
0x0190: 6f70 7340 7265 616c 2e63 6f6d 8201 0030 [email protected]…0
0x01a0: 0c06 0355 1d13 0405 3003 0101 ff30 0d06 …U…0…0…
0x01b0: 092a 8648 86f7 0d01 0104 0500 0381 8100 ..H…
0x01c0: 4a56 e1aa f7ab fbe9 a36b a73d fcd8 4ed3 JV…k.=…N.
0x01d0: 7500 4cb2 48ec db1e 3f93 9b96 5762 42b5 u.L.H…?..WbB.
0x01e0: befd 35b9 a67c 1fe9 1f3d d418 abce 2499 …5…|…=…$.
0x01f0: 9e66 4562 d425 8220 ea80 b54a 87a2 e22f .fEb.%…J…/
0x0200: cc29 d5f6 7cd4 4e22 8ef3 d45d 3744 bce3 .)…|.N"…]7D…
0x0210: a5bf a346 0429 ef1d 3d76 5847 6eb1 21df …F.)…=vXGn.!.
0x0220: d91d 51bf baed 9bb0 4075 b85d 1b70 ab4f …Q…@u.].p.O
0x0230: 090c 8d82 a32e 7312 17f2 5d8a 4a8b aa77 …s…].J…w
0x0240: 0d00 00a3 0201 0200 9e00 9c30 8199 310b …0…1.
0x0250: 3009 0603 5504 0613 0255 5331 1330 1106 0…U…US1.0…
0x0260: 0355 0408 130a 5761 7368 696e 6774 6f6e .U…Washington
0x0270: 3110 300e 0603 5504 0713 0753 6561 7474 1.0…U…Seatt
0x0280: 6c65 311b 3019 0603 5504 0a13 1252 6561 le1.0…U…Rea
0x0290: 6c4e 6574 776f 726b 732c 2049 6e63 2e31 lNetworks,.Inc.1
0x02a0: 0b30 0906 0355 040b 1302 4954 3118 3016 .0…U…IT1.0.
0x02b0: 0603 5504 0313 0f52 6561 6c4e 6574 776f …U…RealNetwo
0x02c0: 726b 7320 4954 311f 301d 0609 2a86 4886 rks.IT1.0…
.H.
0x02d0: f70d 0109 0116 106d 6973 2d6f 7073 4072 …mis-ops@r
0x02e0: 6561 6c2e 636f 6d0e 0000 00 eal.com
11:11:51.700907 IP 192.168.141.130.44841 > 192.168.139.157.636: . ack
1449 win
137 <nop,nop,timestamp 283388 966516201>
0x0000: 4500 0034 64b1 4000 4006 3ba2 c0a8 8d82 E…4d.@.@.;…
0x0010: c0a8 8b9d af29 027c cc90 36b3 e8d8 f956 …).|…6…V
0x0020: 8010 0089 da24 0000 0101 080a 0004 52fc …$…R.
0x0030: 399b dde9 9…
11:11:51.700912 IP 192.168.141.130.44841 > 192.168.139.157.636: . ack
2144 win
182 <nop,nop,timestamp 283388 966516201>
0x0000: 4500 0034 64b2 4000 4006 3ba1 c0a8 8d82 E…4d.@.@.;…
0x0010: c0a8 8b9d af29 027c cc90 36b3 e8d8 fc0d …).|…6…
0x0020: 8010 00b6 d740 0000 0101 080a 0004 52fc …@…R.
0x0030: 399b dde9 9…
11:11:51.702569 IP 192.168.141.130.44841 > 192.168.139.157.636: P
94:106(12) ack
2144 win 182 <nop,nop,timestamp 283388 966516201>
0x0000: 4500 0040 64b3 4000 4006 3b94 c0a8 8d82 E…@d.@.@.;…
0x0010: c0a8 8b9d af29 027c cc90 36b3 e8d8 fc0d …).|…6…
0x0020: 8018 00b6 9aa3 0000 0101 080a 0004 52fc …R.
0x0030: 399b dde9 1603 0100 070b 0000 0300 0000 9…
11:11:51.704083 IP 192.168.141.130.44841 > 192.168.139.157.636: P
106:245(139)
ack 2144 win 182 <nop,nop,timestamp 283388 966516201>
0x0000: 4500 00bf 64b4 4000 4006 3b14 c0a8 8d82 E…d.@.@.;…
0x0010: c0a8 8b9d af29 027c cc90 36bf e8d8 fc0d …).|…6…
0x0020: 8018 00b6 9b22 0000 0101 080a 0004 52fc …”…R.
0x0030: 399b dde9 1603 0100 8610 0000 8200 8004 9…
0x0040: 728c 67d3 e0f8 b954 38d1 b66c ea4e 7020 r.g…T8…l.Np.
0x0050: c4f7 3e9e 215c 4b00 f354 11db 7510 3fab …>.!\K…T…u.?.
0x0060: 0e4a 53ca aa39 7a06 8eea 5374 6b85 8dc1 .JS…9z…Stk…
0x0070: ee20 41e9 0333 c814 b9e4 05b3 b4fe d377 …A…3…w
0x0080: 38dc 5e5c 1ffe 717c 2016 6365 79c1 8702 8.^..q|…cey…
0x0090: fd87 4609 6105 482e 9fb7 a9aa 0235 626a …F.a.H…5bj
0x00a0: 21dc e220 ecf1 cbc7 c3b3 ebaa 96a5 13d0 !..
0x00b0: 46b2 be77 6744 588b 95f8 b4e7 343f 48 F…wgDX…4?H
11:11:51.704098 IP 192.168.141.130.44841 > 192.168.139.157.636: P
245:251(6) ack
2144 win 182 <nop,nop,timestamp 283388 966516201>
0x0000: 4500 003a 64b5 4000 4006 3b98 c0a8 8d82 E…:d.@.@.;…
0x0010: c0a8 8b9d af29 027c cc90 374a e8d8 fc0d …).|…7J…
0x0020: 8018 00b6 9a9d 0000 0101 080a 0004 52fc …R.
0x0030: 399b dde9 1403 0100 0101 9…
11:11:51.710634 IP 192.168.139.157.636 > 192.168.141.130.44841: . ack
251 win
6432 <nop,nop,timestamp 966516202 283388>
0x0000: 4500 0034 2e4a 4000 3f06 7309 c0a8 8b9d E…4.J@.?.s…
0x0010: c0a8 8d82 027c af29 e8d8 fc0d cc90 3750 …|.)…7P
0x0020: 8010 1920 be38 0000 0101 080a 399b ddea …8…9…
0x0030: 0004 52fc …R.
11:11:51.710675 IP 192.168.141.130.44841 > 192.168.139.157.636: P
251:288(37)
ack 2144 win 182 <nop,nop,timestamp 283389 966516202>
0x0000: 4500 0059 64b6 4000 4006 3b78 c0a8 8d82 E…Yd.@.@.;x…
0x0010: c0a8 8b9d af29 027c cc90 3750 e8d8 fc0d …).|…7P…
0x0020: 8018 00b6 9abc 0000 0101 080a 0004 52fd …R.
0x0030: 399b ddea 1603 0100 2039 2d5c 0ceb 1fa1 9…9-.…
0x0040: ba51 2667 0d78 b7cf 766b dede ea9a 1287 .Q&g.x…vk…
0x0050: 0531 9d10 b718 c198 21 .1…!
11:11:51.711379 IP 192.168.139.157.636 > 192.168.141.130.44841: P
2144:2187(43)
ack 288 win 6432 <nop,nop,timestamp 966516202 283389>
0x0000: 4500 005f 2e4b 4000 3f06 72dd c0a8 8b9d E….K@.?.r…
0x0010: c0a8 8d82 027c af29 e8d8 fc0d cc90 3775 …|.)…7u
0x0020: 8018 1920 5409 0000 0101 080a 399b ddea …T…9…
0x0030: 0004 52fd 1403 0100 0101 1603 0100 20b3 …R…
0x0040: 40ab 1858 bda7 54f1 130e 5edb 8b1e 7d9c @…X…T…^…}.
0x0050: c3f8 e42c 722b 1c69 0bbc 15f8 f66b e7 …,r+.i…k.
11:11:51.714944 IP 192.168.141.130.44841 > 192.168.139.157.636: F
288:288(0) ack
2187 win 182 <nop,nop,timestamp 283390 966516202>
0x0000: 4500 0034 64b7 4000 4006 3b9c c0a8 8d82 E…4d.@.@.;…
0x0010: c0a8 8b9d af29 027c cc90 3775 e8d8 fc38 …).|…7u…8
0x0020: 8011 00b6 d64f 0000 0101 080a 0004 52fe …O…R.
0x0030: 399b ddea 9…
11:11:51.716884 IP 192.168.139.157.636 > 192.168.141.130.44841: P
2187:2210(23)
ack 289 win 6432 <nop,nop,timestamp 966516203 283390>
0x0000: 4500 004b 2e4c 4000 3f06 72f0 c0a8 8b9d E…K.L@.?.r…
0x0010: c0a8 8d82 027c af29 e8d8 fc38 cc90 3776 …|.)…8…7v
0x0020: 8018 1920 8bb8 0000 0101 080a 399b ddeb …9…
0x0030: 0004 52fe 1503 0100 12fa ba92 11b8 eb74 …R…t
0x0040: 5f74 65e4 788a 2f88 c7e4 1c te.x./…
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…

11:11:51.716931 IP 192.168.139.157.636 > 192.168.141.130.44841: F
2210:2210(0)
ack 289 win 6432 <nop,nop,timestamp 966516203 283390>
0x0000: 4500 0034 2e4d 4000 3f06 7306 c0a8 8b9d E…4.M@.?.s…
0x0010: c0a8 8d82 027c af29 e8d8 fc4f cc90 3776 …|.)…O…7v
0x0020: 8011 1920 bdcc 0000 0101 080a 399b ddeb …9…
0x0030: 0004 52fe …R.
11:11:51.716936 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…

Then run the script on both boxes, and compare the output. (If it’s
actually establishing an encrypted SSL session then it will look like
garbage, but I suspect that the connection is being rejected in one
case, since that’s what the error message says)

I do not have direct access to the company LDAP server to do this on.
To do
this on the redhat machines, I will need to make arrangements. As you
can see,
the protocol appears to make some headway before the end. The results
look
similar on the 8.04 box.

Xeno C. 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?

Also, on the ubuntu box, try this:

$ irb
irb(main):001:0> require ‘openssl’
=> true
irb(main):002:0>

Brian C. wrote:

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)

Xeno C. 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 C. wrote:

Xeno C. wrote:

not a normal FIN?
SSL-Session:
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?

I doubt very much that installing libopenssl-ruby could affect openssl
(the command line utility)

So far I’ve seen no evidence to suggest that the certificate is the
problem, but now libopenssl-ruby is installed perhaps it is. Look
through the source to LDAP::SSLconn and see what option you need to set
to give the certificate path (or perhaps you can set an environment
variable). Adding some $stderr.puts debugging to see what’s going on
would be a good idea too.

Brian C. wrote:

Xeno C. wrote:

Xeno C. wrote:

not a normal FIN?

I am not finding LDAP::SSLConn or SSLConn in my /usr tree, so presumably
these
are defined in a binary. The only places it is referred to is in an
ldap.rb
file in the core ruby 1.8 area, and then in a bunch of things in the doc
tree.
I guess it makes sense to me that this would not be strewn around as
source code
by default, as you don’t want people hacking your stuff willy nilly.
Can you
recommend a way to get the sources off Ubuntu? I presume they are C,
and I
read/program C, though it’s been a while.

xc

Brian C. wrote:

Say, is anyone else out there able to run the script successfully that I
post?
We can run it from some Redhat and CentOS machines but not from Ubuntu
Server.
It’s just a matter of having a working ldap server with some u/p with
access
available with a similar hostname / port combination and trying it. It
was easy
to get folks to try it in my environment.
xc

Xeno C. wrote:

not a normal FIN?
SSL-Session:
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?

Xeno C. wrote:

My apologies for leaving the wrong heading on there. That last post was
me not
Brian.

Say, it appears my guess was right. the ruby/1.8/openssl.rb has it’s
first
require as ‘openssl.so’. Perhaps I need to get further into this to
understand
how these interfaces to an so library works, but at this point I am a
bit lost.

This isn’t really going anywhere, so I’ll ask the same question one more
time. What happens if you do this in irb?

$ irb
irb(main):001:0> require ‘openssl’
=> true

Do you get “true” like I do, or something else?

I am not finding LDAP::SSLConn or SSLConn in my /usr tree

Can you recommend a way to get the sources off Ubuntu?

  1. Go to google
  2. Type “ruby LDAP::SSLConn”

The top hit is the ruby-ldap project in Sourceforge. So that’s the
easiest way to look at the current source.

The next question is, how did you install ruby-ldap?

(1) If you installed it using ‘gem install …’ then the code will be in
your gems directory, which I believe is /var/lib/gems/1.8 in Ubuntu (I
don’t have an Ubuntu box with Ubuntu ruby to hand right now)

(2) If you installed it from an Ubuntu package, then maybe it has been
broken in a Debian way to separate out the ssl functionality.

$ apt-cache search ldap | grep ruby
libactiveldap-ruby - an object-oriented interface to LDAP for Ruby
libactiveldap-ruby-doc - an object-oriented interface to LDAP for Ruby
libactiveldap-ruby1.8 - an object-oriented interface to LDAP for Ruby
libldap-ruby1.8 - OpenLDAP library binding for Ruby 1.8

So if you have libldap-ruby1.8 installed, you can find the files using

dpkg-query -L libldap-ruby1.8

If this contains only compiled binaries (e.g. .so libraries) then you
can get the Ubuntu source

apt-get source libldap-ruby1.8

which will create the source inside a new directory under the current
directory.

The debian/changelog suggests that ssl support should be included:

libldap-ruby (0.8.0-1) unstable; urgency=low

  • new upstream version.
  • enabled ssl support.

However the dependencies in debian/control don’t list
libopenssl-ruby1.8, so I’m not entirely convinced it’s correct.

Anyway, all the C code is there for you to look at. If it were me, I
would remove the debian libldap-ruby1.8 and install ruby-ldap again from
source, checking carefully all the configure options to ensure that ssl
is enabled. You’ll also need the build dependencies of course; at least
build-essential, libssl-dev and libldap2-dev

Good luck,

Brian.

Xeno C. wrote:

Brian C. wrote:

This isn’t really going anywhere, so I’ll ask the same question one
more time. What happens if you do this in irb?

This is interesting:

root@leopard:~# apt-get source libldap-ruby1.8
Reading package lists… Done
Building dependency tree
Reading state information… Done
Need to get 67.6kB of source archives.
Get:1 http://us.archive.ubuntu.com jaunty/universe libldap-ruby
0.9.7-1build1
(dsc) [648B]
Get:2 http://us.archive.ubuntu.com jaunty/universe libldap-ruby
0.9.7-1build1
(tar) [63.9kB]
Get:3 http://us.archive.ubuntu.com jaunty/universe libldap-ruby
0.9.7-1build1
(diff) [3058B]
Fetched 67.6kB in 0s (72.5kB/s)
sh: dpkg-source: not found
Unpack command ‘dpkg-source -x libldap-ruby_0.9.7-1build1.dsc’ failed.
Check if the ‘dpkg-dev’ package is installed.
E: Child process failed
root@leopard:~#

----snip----

apt stuff is otherwise looking from what I can tell. Have I botched it
or
something?

Brian C. wrote:

This isn’t really going anywhere, so I’ll ask the same question one more
time. What happens if you do this in irb?

$ irb
irb(main):001:0> require ‘openssl’
=> true

Do you get “true” like I do, or something else?

irb(main):001:0> require ‘openssl’
=> true
irb(main):002:0>

I am not finding LDAP::SSLConn or SSLConn in my /usr tree

Can you recommend a way to get the sources off Ubuntu?

  1. Go to google
  2. Type “ruby LDAP::SSLConn”

The top hit is the ruby-ldap project in Sourceforge. So that’s the
easiest way to look at the current source.

Okay great. I will take your suggestion and fit this in as my secondary
project
today. I should be able to get this.

The next question is, how did you install ruby-ldap?

I believe it got installed by installing apt-get libactiveldap-ruby,
which was
what I originally intended to use, but then all the simplest examples
for what I
wanted were for plain ruby-ldap, so I checked it and it had already been
installed. Perhaps I need to apt-get install from another package
though.

libactiveldap-ruby-doc - an object-oriented interface to LDAP for Ruby
libactiveldap-ruby1.8 - an object-oriented interface to LDAP for Ruby
libldap-ruby1.8 - OpenLDAP library binding for Ruby 1.8

Actually, that is the exact command I used to find it.

which will create the source inside a new directory under the current
directory.

Okay. That’s what I needed. Last time I did stuff like this was in
2002 I
think and I used tgz files and such.

Anyway, all the C code is there for you to look at. If it were me, I
would remove the debian libldap-ruby1.8 and install ruby-ldap again from
source, checking carefully all the configure options to ensure that ssl
is enabled. You’ll also need the build dependencies of course; at least
build-essential, libssl-dev and libldap2-dev

Okay. The onus is on me then. I will likely follow your instructions
exactly.
I should be able to get started before noon if I’m not pulled off by a
fire.

Thank you very much again for your support Brian.

Sincerely, Xeno

Xeno C. wrote:

Doh. Sorry, I got it.

xc

Xeno C. wrote:

Okay Brian, having installed with apt-get source libldap-ruby1.8,
openssl, and
libopenssl-ruby1.8, I am now in a quandry in two ways:

  1. I don’t see any .c files pertinent to any of these areas on my
    system.
  2. I found a pgp complaint saying I don’t have a public key (perhaps
    this is my
    problem):

root@leopard:~# apt-get source openssl
Reading package lists… Done
Building dependency tree
Reading state information… Done
NOTICE: ‘openssl’ packaging is maintained in the ‘Svn’ version control
system at:
svn://svn.debian.org/pkg-openssl/openssl/
Need to get 3415kB of source archives.
Get:1 http://us.archive.ubuntu.com jaunty/main openssl 0.9.8g-15ubuntu3
(dsc)
[1429B]
Get:2 http://us.archive.ubuntu.com jaunty/main openssl 0.9.8g-15ubuntu3
(tar)
[3355kB]
Get:3 http://us.archive.ubuntu.com jaunty/main openssl 0.9.8g-15ubuntu3
(diff)
[58.6kB]
Fetched 3415kB in 6s (493kB/s)
gpg: Signature made Fri 27 Mar 2009 06:26:08 AM PDT using DSA key ID
174BF01A
gpg: Can’t check signature: public key not found
dpkg-source: extracting openssl in openssl-0.9.8g
dpkg-source: info: unpacking openssl_0.9.8g.orig.tar.gz
dpkg-source: info: applying openssl_0.9.8g-15ubuntu3.diff.gz
----snip----
So I wonder if I need to find a public key to get my c files? Am I not
seeing
something obvious?