------------------------------
I don't have any insight off the top of my head beyond what you've
already tried.
You could take a packet trace with ethereal or the like and see if
there's anything
interesting in the SSL handshake.
Is FDS dependent on specific versions of libssl3.so or ?... The thing
that confuses me the most is that it all seems to be working fine in
every other case. I am still not sure there isn't a problem with my
Win2003 domain controller...
FDS should be used with the version of NSS that it was built against.
There will be some minor functionality differences between NSS releases
and bug fixes, but I wouldn't expect much sensitivity to NSS version
as far as basic functionality like this goes.
Bottom line is that if you can use the 'ldapsearch' command (the Mozilla
version that ships with FDS), pointed at the same cert database that the
server is using, to connect to your AD, then FDS's Winsync code should
be able to connect too : the code paths are essentially identical.
Well, I think I found the problem...
Here is the output of ssltap that captured a request to the DC:
--> [
alloclen = 54 bytes
(54 bytes of 54)
[Wed Feb 1 12:39:36 2006] [ssl2] ClientHelloV2 {
version = {0x03, 0x01}
cipher-specs-length = 27 (0x1b)
sid-length = 0 (0x00)
challenge-length = 16 (0x10)
cipher-suites = {
(0x000004) SSL3/RSA/RC4-128/MD5
(0x00feff) SSL3/RSA-FIPS/3DESEDE-CBC/SHA
(0x00000a) SSL3/RSA/3DES192EDE-CBC/SHA
(0x00fefe) SSL3/RSA-FIPS/DES-CBC/SHA
(0x000009) SSL3/RSA/DES56-CBC/SHA
(0x000064) TLS/RSA-EXPORT1024/RC4-56/SHA
(0x000062) TLS/RSA-EXPORT1024/DES56-CBC/SHA
(0x000003) SSL3/RSA/RC4-40/MD5
(0x000006) SSL3/RSA/RC2CBC40/MD5
}
session-id = { }
challenge = { 0xc930 0x4121 0xe11d 0x443a 0x77b4 0xaef1
0x13b0 0xc017 }
}
]
<-- [
(2896 bytes, making 2896 of 4836)
]
<-- [
(1945 bytes, making 4836 of 4836)
SSLRecord { [Wed Feb 1 12:39:36 2006]
type = 22 (handshake)
version = { 3,1 }
length = 4836 (0x12e4)
handshake {
type = 2 (server_hello)
length = 70 (0x000046)
ServerHello {
server_version = {3, 1}
random = {...}
session ID = {
length = 32
contents = {..}
}
cipher_suite = (0x0004) SSL3/RSA/RC4-128/MD5
}
type = 11 (certificate)
length = 1423 (0x00058f)
CertificateChain {
chainlength = 1420 (0x058c)
Certificate {
size = 1417 (0x0589)
data = { saved in file 'cert.001' }
}
}
type = 13 (certificate_request)
length = 3327 (0x000cff)
type = 14 (server_hello_done)
length = 0 (0x000000)
}
}
]
--> [
(7 bytes of 2)
SSLRecord { [Wed Feb 1 12:39:36 2006]
type = 21 (alert)
version = { 3,1 }
length = 2 (0x2)
fatal: unknown CA
}
]
Looking through this looks like it is the FDS server that is saying that
the CA is unknown, but it it refering to the response from the DC, or
it's own certificate store? Looking at the dump of extended data from
ssltap, the response from the DC indicates it is using a cert not signed
by itself (a CA), but by another server that is not a DC, and in fact a
non-critical server. The validity of that CA and all it's certificates
expired at the time that FDS stopped synconizing. Why our Windows Admin
is using CAs around the network willi-nillie is a mystery to me. I will
get rid of that cert, and make sure that it is offering up a cert that
is signed by a third party CA (like CACert.org)
Thank you Dave. It looks like you were right about this being a stumper
as long as we are looking for the problem on FDS.
--
Daniel Shackelford
Systems Administrator
Technology Services
Spring Arbor University
517 750-6648
"For even the Son of Man did not come to be served, but to serve, and to give His life a ransom for many"
Mark 10:45
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
