https://bugs.openldap.org/show_bug.cgi?id=8861

Quanah Gibson-Mount quanah@openldap.org changed:

What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 CC| |nivanova@symas.com Status|UNCONFIRMED |CONFIRMED

--- Comment #2 from Quanah Gibson-Mount quanah@openldap.org --- 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.