Hello,
I have recently upgraded from openldap 2.4.45 to 2.5.53. I are running into one issue when running ldapsearch wth StartTLS locally on the openldap servers. I get the following error whereas I did not prior to upgrade. Any input/suggestions welcome.
$ ldapsearch -ZZ -LLL -H ldap://<uri> -x -D "cn=admin, dc=<test.dc,dc=com" -b "dc=test,dc=com" -w ${pw} ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain)
Here is the debug: -------------- TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 3, err: 19, subject: /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority, issuer: /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority 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). ldap_err2string ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain) --------------
This does not happen with the same ldapsearch done remotely - TLS works just fine with remote ldapsearch queries. Running ldapsearch without StartTLS locally on the server works just fine as well.
Prior to this upgrade, we had built openldap with MozNSS (--with-tls=moznss) but now are using the recommended openssl. With our earlier version, running ldapsearch with StartTLS locally on the openldap servers worked without issue.
Our certs are not self signed but it appears tls with ldapsearch is seeing the CA cert from our CA as self signed when running locally on the server. Is this even a problem since remote connectivity with TLS works fine? Since we were running moznss prior, I am not sure what the expected behavior is now but it seems that it should work the same as before.
A few more details: ------------------ -Servers are CentOS Linux release 7.5
-We are running Openldap version: OpenSSL 1.0.2k-fips 26 Jan 2017
-We are using the same certs (no changes to the certs as part of the upgrade)
-Here is partial output from openssl s_client -connect <hostname-here>:636 (same result with openssl s_client -connect <hostname-here>:389 -starttls ldap): This shows return code of 0 (ok): -------------- New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2
Verify return code: 0 (ok) --------------
-Ran openssl s_client -verify 3 -connect localhost:636 (and with hostname as well) and openssl s_client -showcerts -connect localhost:636. Both return code 0 (ok): Verify return code: 0 (ok)
-Checked the certs: openssl verify -verbose -x509_strict -CAfile ca.crt slapd.crt slapd.crt: OK
-Here is our cert config: olcTLSCACertificateFile: /etc/openldap/certs/ca.crt olcTLSCertificateFile: /etc/openldap/certs/slapd.crt olcTLSCertificateKeyFile: /etc/openldap/certs/slapd.key
For reference, here is the debug output when running the same ldapsearch command locally on the server on our previous version (2.4.45 with moznss) and the same cert is validated.
-------------- TLS: certdb config: configDir='/etc/openldap/certs' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: using moznss security dir /etc/openldap/certs prefix . TLS: certificate [CN=*<test-domain-here>,OU=Domain Control Validated] is valid TLS certificate verification: subject: CN=*<test-domain-here>,OU=Domain Control Validated, issuer: CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O=%22GoDaddy.com, Inc.",L=Scottsdale,ST=Arizona,C=US, cipher: AES-256-GCM, security level: high, secret key bits: 256, total key bits: 256, cache hits: 0, cache misses: 0, cache not reusable: 0 ldap_sasl_bind --------------
Any suggestions are appreciated. Thanks. Paul
Update: Commenting out this line in /etc/openldap/ldap.conf seems to fix.
#TLS_CACERTDIR /etc/openldap/certs
I see now I missed the ldap.conf.rpmnew file after upgrade which by default has TLS_CACERT commented out. I still am having trouble understanding why this worked before but not after upgrade (assuming related to moznss but not certain). Can someone help explain the use of TLS_CACERTDIR or TLS_CACERT in the ldap.conf file vs being applied via ldif (as I have done and is noted above)? Does setting the parameter in ldap.conf mean the shared system certs are used? The documentation is confusing me. Thanks.
One more update: I edited /etc/openldap/ldap.conf to test TLS_CACERT /etc/openldap/certs/ca.crt and it works with that config. I also re-read the documentation and clarified for myself that if either of these (TLS_CACERT or TLS_CACERTDIR) are NOT set in ldap.conf, that is when the system certs are used, so I believe I definitely want this set in ldap.conf. I suppose the question now is why didn't this work for me with TLS_CACERTDIR but does with TLS_CACERT?
--On Wednesday, September 30, 2020 11:47 PM +0000 paul.jc@yahoo.com wrote:
One more update: I edited /etc/openldap/ldap.conf to test TLS_CACERT /etc/openldap/certs/ca.crt and it works with that config. I also re-read the documentation and clarified for myself that if either of these (TLS_CACERT or TLS_CACERTDIR) are NOT set in ldap.conf, that is when the system certs are used, so I believe I definitely want this set in ldap.conf. I suppose the question now is why didn't this work for me with TLS_CACERTDIR but does with TLS_CACERT?
With OpenSSL, the CA Cert directory needs to contain relevant hashes for each CA cert if you want to use the TLS_CACERTDIR setting. I don't know whether or not your CA directory contains those.
I would note that (at least for RHEL7), RedHat kept a moznss "bridge" patch so that the certificate code would continue to work as it did with moznss. https://git.centos.org/rpms/openldap/blob/c7/f/SOURCES/openldap-tlsmc.patch
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org