LDAPs updating tls_cacertfile and tls_req_cert on the fly

asked 2016-03-11 10:30:54 -0500

pentatonic gravatar image

I have been testing the Keystone behavior (with trunk Mitaka of a week ago or so) related to LDAPs integration. Most specifically playing with turning certificate validation on/off, and placing the correct or incorrect ca certificate in the location pointed at by the tls_cacertfile parameter of the domain config api.

What I noticed is that while I can dynically update:
"url": "ldaps://192.168.228.1:10636",
"tls_cacertfile": "/etc/keystone/ldapcerts/ldap.pem", #toggle between no file, correct file, incorrect file "tls_req_cert": "demand" # toggle between allow, never, demand

and have the domain config correctly updated and reloaded, the behavior is not consistent. Or more exactly, trust wise, it is stuck on the last behavior encountered by Keystone the last time it talked to that server.

For example, set: "url": "ldaps://192.168.228.1:10636",
"tls_cacertfile": "", # empty path "tls_req_cert": "never"

--> as expected, connection is ok because I set "never".

I now switch to: "url": "ldaps://192.168.228.1:10636",
"tls_cacertfile": "/etc/keystone/ldapcerts/ldap.pem", # incorrect file or bogus "tls_req_cert": "demand"

--> connection continues to work even though I switched to demand and put a fake file in place.

After Keystone restart, things work as expected (fail with the bad cert, then after I put the good cert in place and restart again, works).

The point is: unless Keystone is restarted, the trust behavior is unreliable. I was hoping that the domain config REST api being dynamic, I would expect the trust behavior to follow suit.

Do you know if this is a bug or a limitation of the implementation (which perhaps has ssl contexts already initialized and not able to "reload" or invalidate them on the fly)

edit retag flag offensive close merge delete