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

Quanah Gibson-Mount <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |[email protected]
             Status|UNCONFIRMED                 |CONFIRMED

--- Comment #2 from Quanah Gibson-Mount <[email protected]> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Reply via email to