Created attachment 520430 [details] Patch as described in the comment Description of problem: Here is the context: _ The provider accepts ldaps (SSL) connections without client certificate, authentication via a simple bind. _ The replica also accepts ldaps connections: thus it has a server certificate. It uses syncrepl from the ldaps provider. The problem is: _ If the tls_cert/tls_key syncrepl parameters are not specified in the replica configuration, the SERVER kex+cert are inherited (although syncrepl is a client application). _ Any attempts to set these parameters always fail unless they provide a valid key/certificate file pair. In other words, there is no way to disable client certificate in the replica. _ The only way to disable syncrepl client certificate is to not have a ldap server certificate, effectively disabling ldaps service :-( Version-Release number of selected component (if applicable): openldap-2.4.23-4.fc14 How reproducible: Always. Steps to Reproduce: 1. Configure provider and replica to serve ldaps. 2. Configure delta-syncrepl replication as stated in http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl (but use bdb backend). 3. Add "tls_cacert=<your ca-bundle file>" to the syncrepl parameter list in replica configuration. 4. Make sure the provider= parameter specifies an ldaps:// url. 5. Do not set "starttls" (use SSL instead of TLS). Actual results: No replication. Viewing the debug shows that the server certificate usage as client certificate for syncrepl ends in a "invalid token" error, effectively disabling SSL. Sniffing with wireshark shows connections every retry time, but they are immediately terminated by the replica. Expected results: Proper replication. The connection should be followed by a successful SSL handshake. Additional info: Setting syncrepl "tls_cert=" without name fails with "file not found". Using "tls_cert=/dev/null" fails with "/dev/null is not a file". Several error reports of this problem may be found on Internet. The general answer is "the inheritance is here by design and it's not a bug". However it really lacks a feature to disable client key/cert. I have designed a patch that allows to specify empty "tls_xxx=" in order to disable client certificate. Please find it attached. With the patch applied, by telling in syncrepl: tls_cacert=<your ca-bundle> tls_cert= tls_key= the replication works without client certificate on an SSL provider connection.
Another workaround is to set the olcTLSVerifyCert: allow setting in the provider TLS/SSL configuration in cn=config. The problem is that the default is try - this makes the provider request a client cert from the consumer - the consumer sends the one it has inherited from the TLS server context, which is the server cert. Have you tried to open an upstream ITS against openldap? If so, do you have that ITS number?
I did not check your workaround, but I don't think it's OK: _ olcTLSVerifyCert does not exist: you probably mean olcTLSVerifyClient _ "olcTLSVerifyCLient allow" means you MAY have a client certificate: what is needed in my context is "olcTLSVerifyCLient never", which is the default. In fact, the underlying problem effectively occurs at certificate load time. I did not report this upstream. Please fill free to do it. Thanks for your attention.
corrections to comment 2: s/fill/feel/ %s/CLient/Client/g :-)
(In reply to comment #2) > I did not report this upstream. Please fill free to do it. I have opened an upstream report and submitted your patch: http://www.openldap.org/its/index.cgi?findid=7042
(In reply to comment #2) > I did not report this upstream. Please fill free to do it. Patrick, if you want to get the patch included upstream (and therefore included in future version of Fedora distribution) you will have to permit the patch inclusion into OpenLDAP (or maybe resubmit the patch). They have a patch acceptance policy which refuses third-party patch submissions and all patches have to be submitted by the author. This is all you might need: http://www.openldap.org/devel/contributing.html http://www.openldap.org/its/index.cgi?findid=7042 http://www.openldap.org/lists/openldap-bugs/201109/msg00017.html openldap-its?subject=(ITS#7042) I'm sorry that upstream requires this even for so simple patches.
Resolved in: openldap-2.4.24-5.fc15 openldap-2.4.26-3.fc16 openldap-2.4.26-3.fc17 Not critical for F14.
openldap-2.4.26-3.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/openldap-2.4.26-3.fc16
openldap-2.4.24-5.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/openldap-2.4.24-5.fc15
Package openldap-2.4.24-5.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing openldap-2.4.24-5.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/openldap-2.4.24-5.fc15 then log in and leave karma (feedback).
Thanks for your action. I did not bumped karmas because I currently run F14 (but I've a homemade patched version, so don't worry!) I'm sorry upstream showed bad mood to your proposal: I just tried to insist as the "patch author" ;-) http://www.openldap.org/its/index.cgi/Incoming?id=7042#followup4 ... let's wait and see !
openldap-2.4.26-5.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
openldap-2.4.24-5.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
2.5 years after, I would just say "thank you" to the maintainers of this package for having taken care and adapted my patch to the subsequent openldap versions, knowing that this part of code has changed and the patch not accepted upstream. It's really valuable to me: THANK YOU SO MUCH! Patrick