Not configuring use_tls when ldaps is used is intentional actually. use_tls has a confusing naming upstream. What it really means is use_starttls which is mutually exclusive with using ldaps explicitly.
There is also no reason to set `tls_req_cert = allow` instead of "demand" at the client side if ldaps is used. After all, if we use ldaps we want the client always perform server certificate checks not just allow them.
https://www.openldap.org/doc/admin21/tls.html
"TLS_REQCERT
This directive is equivalent to the server's TLSVerifyClient option. However, ***for clients*** the default value is demand and there ***generally is no good reason to change this setting***."
Not configuring use_tls when ldaps is used is intentional actually. use_tls has a confusing naming upstream. What it really means is use_starttls which is mutually exclusive with using ldaps explicitly.
https:/ /github. com/openstack/ charm-keystone- ldap/commit/ 5d644391adb00c4 eda292db27f9e0f 702d924220
"* use_tls option should only be used for StartTLS and will result in an error if used with a URL that starts with ldaps;"
And Keystone doc for this option is quite explicit:
https:/ /github. com/openstack/ keystone/ blob/stable/ queens/ keystone/ conf/ldap. py#L361- L369
use_tls = cfg.BoolOpt(
# ...
Do not set this option if you are using LDAP over SSL (LDAPS) instead of TLS.
The Keystone code itself will throw an assertion if ldaps is used with use_tls:
https:/ /github. com/openstack/ keystone/ blob/stable/ queens/ keystone/ identity/ backends/ ldap/common. py#L579- L583 _('Invalid TLS / LDAPS combination'))
if use_tls and using_ldaps:
raise AssertionError(
There is also no reason to set `tls_req_cert = allow` instead of "demand" at the client side if ldaps is used. After all, if we use ldaps we want the client always perform server certificate checks not just allow them.
https:/ /www.openldap. org/doc/ admin21/ tls.html
"TLS_REQCERT
This directive is equivalent to the server's TLSVerifyClient option. However, ***for clients*** the default value is demand and there ***generally is no good reason to change this setting***."