On 03/05/11 21:41, Alexander Clouter wrote: > Daniele Albrizio <[email protected]> wrote: >> >> I suspect the "cacertfile" attribute is not correctly re-instantiated >> and only the value of the first request is used to check against when >> instantiating a new ldaps connection. >> > Without a doubt the chaining is not working on your LDAP servers. What
What I suspect is that this is not working with ANY ldap servers as long as you have multiple ldaps backend configured and ldap servers are secured by SSL certificates signed by different CAs > is the full output of: > > openssl s_client -connect myAD.ds.units.it:636 -showcerts > openssl s_client -connect myopenldap.units.it:636 -showcerts http://pastebin.com/kyb34c9M for the first http://pastebin.com/Kqd12KQL for the second > You can pipe the server cert (cut'n'paste on stdin) through the > following to see the useful parts of the certs: > > openssl x509 -noout -text Yes, perhaps the problem is not whether the verification is successful or not (it works on each server only if we are in the first ldaps conection n a freshly started freeradius), but what happens if the Nth request with N != 1st goes to the other ldap server. This Nth request fails with TLS: peer cert untrusted or revoked (0x42) but it is configured correctly. I suspect this could be a bug in the way multiple CA cert attribute of subsequent requests are handled in freeradius code. > You probably will find if you change those tls 'demands' to 'never' > things work, but then it kinda is self defeating :) Obviously, I don't want that :) -- Daniele ALBRIZIO - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
