Bug 734187 - allow unsetting of tls_* syncrepl options
Summary: allow unsetting of tls_* syncrepl options
Alias: None
Product: Fedora
Classification: Fedora
Component: openldap
Version: 15
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Jan Vcelak
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-08-29 16:36 UTC by Patrick Monnerat
Modified: 2014-04-07 13:45 UTC (History)
3 users (show)

Fixed In Version: openldap-2.4.24-5.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-11-17 23:41:17 UTC

Attachments (Terms of Use)
Patch as described in the comment (2.66 KB, patch)
2011-08-29 16:36 UTC, Patrick Monnerat
no flags Details | Diff

Description Patrick Monnerat 2011-08-29 16:36:31 UTC
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):

How reproducible:

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>

the replication works without client certificate on an SSL provider connection.

Comment 1 Rich Megginson 2011-08-29 16:53:45 UTC
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?

Comment 2 Patrick Monnerat 2011-08-30 10:07:02 UTC
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.

Comment 3 Patrick Monnerat 2011-08-30 12:08:58 UTC
corrections to comment 2:



Comment 4 Jan Vcelak 2011-09-12 16:35:51 UTC
(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:

Comment 5 Jan Vcelak 2011-09-12 17:30:40 UTC
(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:

I'm sorry that upstream requires this even for so simple patches.

Comment 6 Jan Vcelak 2011-09-12 17:41:34 UTC
Resolved in:


Not critical for F14.

Comment 7 Fedora Update System 2011-09-12 18:54:41 UTC
openldap-2.4.26-3.fc16 has been submitted as an update for Fedora 16.

Comment 8 Fedora Update System 2011-09-12 19:01:20 UTC
openldap-2.4.24-5.fc15 has been submitted as an update for Fedora 15.

Comment 9 Fedora Update System 2011-09-13 05:43:05 UTC
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:
then log in and leave karma (feedback).

Comment 10 Patrick Monnerat 2011-10-20 17:17:03 UTC
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" ;-)

... let's wait and see !

Comment 11 Fedora Update System 2011-11-05 01:24:32 UTC
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.

Comment 12 Fedora Update System 2011-11-17 23:41:17 UTC
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.

Comment 13 Patrick Monnerat 2014-04-07 13:45:25 UTC
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!

Note You need to log in before you can comment on or make changes to this bug.