TLS parameter changes or removed

Bug #1819054 reported by Narinder Gupta on 2019-03-07
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Keystone LDAP integration

Bug Description

TLS parameters in Keystone.conf template file needs to be modified to make use of tls certificate. Current parameters are hardcoded. use_tls no such config in config and even ldap-server with ldaps://ip/ does not change it to true.

use_tls = {{ options.use_tls }}
tls_req_cert = demand

While customer requirement is to use
tls_req_cert = allow
use_tls = true

There are two options:
1. Add tls_req_cert as a config option and fix use_tls
2. Remove both the options so that changes can be managed using ldap-config-flags which write into the same file.

I would prefer the later one though.

David Ames (thedac) wrote :
Changed in charm-keystone-ldap:
status: New → Triaged
importance: Undecided → Critical
milestone: none → 18.08
milestone: 18.08 → 19.04
Dmitrii Shcherbakov (dmitriis) wrote :

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.
"* 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:
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:
    if use_tls and using_ldaps:
        raise AssertionError(_('Invalid TLS / LDAPS combination'))

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.
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***."

James Page (james-page) on 2019-03-11
Changed in charm-keystone-ldap:
status: Triaged → Incomplete
importance: Critical → Undecided
David Ames (thedac) on 2019-04-17
Changed in charm-keystone-ldap:
milestone: 19.04 → 19.07
Narinder Gupta (narindergupta) wrote :

Agree with dmitri so we can close this issue now.

David Ames (thedac) on 2019-08-12
Changed in charm-keystone-ldap:
milestone: 19.07 → 19.10
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers