TLS parameter changes or removed

Bug #1819054 reported by Narinder Gupta
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Keystone LDAP integration
Expired
Undecided
Unassigned

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.

Revision history for this message
David Ames (thedac) wrote :
Changed in charm-keystone-ldap:
status: New → Triaged
importance: Undecided → Critical
milestone: none → 18.08
milestone: 18.08 → 19.04
Revision history for this message
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.

https://github.com/openstack/charm-keystone-ldap/commit/5d644391adb00c4eda292db27f9e0f702d924220
"* 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
    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.

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

James Page (james-page)
Changed in charm-keystone-ldap:
status: Triaged → Incomplete
importance: Critical → Undecided
David Ames (thedac)
Changed in charm-keystone-ldap:
milestone: 19.04 → 19.07
Revision history for this message
Narinder Gupta (narindergupta) wrote :

Agree with dmitri so we can close this issue now.

David Ames (thedac)
Changed in charm-keystone-ldap:
milestone: 19.07 → 19.10
David Ames (thedac)
Changed in charm-keystone-ldap:
milestone: 19.10 → 20.01
James Page (james-page)
Changed in charm-keystone-ldap:
milestone: 20.01 → 20.05
David Ames (thedac)
Changed in charm-keystone-ldap:
milestone: 20.05 → 20.08
James Page (james-page)
Changed in charm-keystone-ldap:
milestone: 20.08 → none
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for OpenStack Keystone LDAP integration because there has been no activity for 60 days.]

Changed in charm-keystone-ldap:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.