--On Friday, July 07, 2017 6:27 PM +0000 Jon C Kidder jckidder@aep.com wrote:
olcDbStartTLS: ldaps starttls=no tls_cacert="/appl/openldap/etc/openldap/tls/cacerts.cer" tls_reqcert=demand tls_crlcheck=none
There is no such option as "starttls" for the olcDbStartTLS parameter.
From the man page:
tls {[try-]start|[try-]propagate|ldaps} [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 the use of TLS when a regular connection is initialized. The StartTLS extended operation will be used unless the URI directive protocol scheme is ldaps://. In that case this keyword may only be set to "ldaps" and the StartTLS operation will not be used. 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 not recommended.
My guess then is everything past that point is ignored, since you've provided invalid configuration data.
The attribute is also poorly named, as it may or may not have anything to do with startTLS. More likely it should have just been called olcDbTLS
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
I've removed the starttls=no syntax and the line now reads.
olcDbStartTLS: ldaps tls_cacert="/appl/openldap/etc/openldap/tls/cacerts.cer " tls_reqcert=demand tls_crlcheck=none
I have verified the change propagated to the configuration directory and restarted the instance. I saw no errors during configuration parsing in the log. I am still seeing this error when the chain overlay tries to follow the referral but no complaints when syncrepl connects.
TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 19, subject: /C=US/ST=Ohio/L=Columbus/O=American Electric Power/OU=Complex - Middleware/CN=AEP Root CA (2014)/emailAddress=middleware@aep.com, issuer: /C=US/ST=Ohio/L=Columbus/O=American Electric Power/OU=Complex - Middleware/CN=AEP Root CA (2014)/emailAddress=middleware@aep.com TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in error TLS trace: SSL_connect:error in error TLS: can't connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain).
Thanks again for the assist(s). Any other thoughts? -Jon
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@symas.com] Sent: Friday, July 07, 2017 2:03 PM To: Jon C Kidder; openldap-technical@OpenLDAP.org Subject: [EXTERNAL] Re: back-ldap and ldaps not working
This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attachments.
********************************************************************** --On Friday, July 07, 2017 6:27 PM +0000 Jon C Kidder jckidder@aep.com wrote:
olcDbStartTLS: ldaps starttls=no tls_cacert="/appl/openldap/etc/openldap/tls/cacerts.cer" tls_reqcert=demand tls_crlcheck=none
There is no such option as "starttls" for the olcDbStartTLS parameter.
From the man page:
tls {[try-]start|[try-]propagate|ldaps} [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 the use of TLS when a regular connection is initialized. The StartTLS extended operation will be used unless the URI directive protocol scheme is ldaps://. In that case this keyword may only be set to "ldaps" and the StartTLS operation will not be used. 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 not recommended.
My guess then is everything past that point is ignored, since you've provided invalid configuration data.
The attribute is also poorly named, as it may or may not have anything to do with startTLS. More likely it should have just been called olcDbTLS
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.symas.com&d=DwIC... >
Jon C Kidder wrote:
TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 19, subject: […] TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA
I think this messages are pretty clear. Something's wrong on your back-ldap proxy with validating the target server's certificate.
It's a pretty good idea to verify first on the command-line:
openssl s_client -connect ldap.example.com:636 -CAfile /path/to/rootca.crt
LDAPTLS_CACERT=/path/to/rootca.crt ldapwhoami ldaps://ldap.example.com
Ciao, Michael.
Thanks Michael. The message is clear but the solution isn't. I think you missed the part about this exact same slapd node being a replication consumer replicating successfully using the exact same certificate/TLS setup. Just for added validation the masters have been active for a couple years serving a very active test environment with ~100 test clients connecting via ldaps. Something appears to be hinky with the configuration processing or certificate validation processing in back-ldap. My gut is that olcDBStartTLS isn't being converted/formatted correctly or isn't being parsed correctly and the option to set the path to the CA cert file is being ignored.
-Jon
On Jul 8, 2017, at 6:39 AM, Michael Ströder michael@stroeder.com wrote:
Jon C Kidder wrote:
TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 19, subject: […] TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA
I think this messages are pretty clear. Something's wrong on your back-ldap proxy with validating the target server's certificate.
It's a pretty good idea to verify first on the command-line:
openssl s_client -connect ldap.example.com:636 -CAfile /path/to/rootca.crt
LDAPTLS_CACERT=/path/to/rootca.crt ldapwhoami ldaps://ldap.example.com
Ciao, Michael.
Jon C Kidder wrote:
My gut is that olcDBStartTLS isn't being converted/formatted correctly or isn't being parsed correctly and the option to set the path to the CA cert file is being ignored.
I vaguely remember there were bugs in back-ldap/back-meta ignoring TLS options. The work-around back then was to set env var LDAPTLS_CACERT and friends when starting slapd to let libldap pick up the TLS options from env.
Should be fixed in recent releases OpenLDAP though.
Ciao, Michael.
openldap-technical@openldap.org
-
Jon C Kidder -
Michael Ströder -
Quanah Gibson-Mount