On 04/05/11 09:37, Daniele Albrizio wrote:
On 03/05/11 21:41, Alexander Clouter wrote:
Daniele Albrizio<albrizio@univ.trieste.it> 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.
FreeRADIUS just calls: ldap_set_option( NULL, LDAP_OPT_X_TLS_CACERTFILE, ...) ...and similar in rlm_ldap.c:ldap_connect Interestingly, the 1st argument is NULL, not the LDAP* instance which has been created higher up, meaning those options are being (re)set globally, not per-connection. I wonder if that's the problem? You could try: perl -pe 's/(ldap[_a-z0-9]+)\(\s*NULL,/\1(ld,/g' src/modules/rlm_ldap/rlm_ldap.c ...which will change the above to: ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTFILE, ...) i.e. they'll be set on the connection created, not globally.