Full_Name: Quanah Gibson-Mount Version: HEAD OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) The slapd-asyncmeta(5) and slapd-meta(5) man pages are missing the fact that they support the "ldaps" option to the "tls" keyword. This section should be updated along the lines of back-ldap which also has this option as a keyword.
"none" is also missing
Hi Nadya, In looking over the back-meta man page and code and comparing it to what's in back-ldap, I think the man page for back-meta needs significant updating for the TLS option. Can you confirm the following? In back-ldap, we have: tls {none|[try-]start|[try-]propagate|ldaps} [starttls=no] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_crlcheck=none|peer|all] Specify TLS settings for regular connections. The first parameter only applies to ldap:// connections and so at the moment, none and ldaps are equivalent. With propagate, the proxy issues StartTLS operation only if the original connection has a TLS layer set up. The try- prefix instructs the proxy to continue operations if the StartTLS operation failed; its use is not recommended. The TLS settings default to the same as the main slapd TLS settings, except for tls_reqcert which defaults to "demand" and starttls which is overshadowed by the first keyword and thus ignored. I believe all of the above options also apply to back-meta. Are the caveats about tls_reqcert the same? For back-meta, all we have currently is: tls {[try-]start|[try-]propagate} execute the StartTLS extended operation when the connection is initialized; only works if the URI directive protocol scheme is not ldaps://. propagate issues the StartTLS operation only if the original connection did. The try- prefix instructs the proxy to continue operations if the StartTLS operation failed; its use is highly deprecated. If set before any target specification, it affects all targets, unless overridden by any per-target directive.
(In reply to Quanah Gibson-Mount from comment #0) > Full_Name: Quanah Gibson-Mount > Version: HEAD > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > The slapd-asyncmeta(5) and slapd-meta(5) man pages are missing the fact that > they support the "ldaps" option to the "tls" keyword. This section should be > updated along the lines of back-ldap which also has this option as a keyword. Sounds more like the back-ldap manpage is wrong. The use of "ldaps" is implicit in the URI, so there's no point in supporting it here and it should be an error to allow it here. In particular it makes no sense to allow it here if it differs from the URI.
(In reply to Howard Chu from comment #3) > Sounds more like the back-ldap manpage is wrong. The use of "ldaps" is > implicit in the URI, so there's no point in supporting it here and it should > be an error to allow it here. In particular it makes no sense to allow it > here if it differs from the URI. Ok, although that doesn't entirely answer the rest of my question (i.e., about tls_reqcert etc missing from back-meta). Ironically I would note you're literally the person who added the "ldaps" option to back-ldap. a6a8fb514b (Howard Chu 2007-01-08 23:36:24 +0000 511) { BER_BVC( "ldaps" ), LDAP_BACK_F_TLS_LDAPS },
(In reply to Quanah Gibson-Mount from comment #4) > (In reply to Howard Chu from comment #3) > > > Sounds more like the back-ldap manpage is wrong. The use of "ldaps" is > > implicit in the URI, so there's no point in supporting it here and it should > > be an error to allow it here. In particular it makes no sense to allow it > > here if it differs from the URI. > > Ok, although that doesn't entirely answer the rest of my question (i.e., > about tls_reqcert etc missing from back-meta). > > Ironically I would note you're literally the person who added the "ldaps" > option to back-ldap. > > a6a8fb514b (Howard Chu 2007-01-08 23:36:24 +0000 511) { > BER_BVC( "ldaps" ), LDAP_BACK_F_TLS_LDAPS }, The original text in that commit is more clear: +Specify the use of TLS when a regular connection is initialized. The +StartTLS extended operation will be used unless the URI directive protocol +scheme is \fBldaps://\fP. In that case this keyword may only be +set to "ldaps" and the StartTLS operation will not be used. So this setting is required to agree with the URI. The only reason this keyword is defined here is because slap_bindconf_unparse emits it for ldaps URIs and it would have taken extra work to omit it.
fixed in master
Commits: • dfd8515e by Howard Chu at 2021-02-18T14:33:16+00:00 ITS#8861 clarify tls keyword