Bug 734187

Summary: allow unsetting of tls_* syncrepl options
Product: [Fedora] Fedora Reporter: Patrick Monnerat <patrick>
Component: openldapAssignee: Jan Vcelak <jvcelak>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: jvcelak, rmeggins, tsmetana
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openldap-2.4.24-5.fc15 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-17 23:41:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch as described in the comment none

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):
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.
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:

s/fill/feel/
%s/CLient/Client/g

:-)
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:
http://www.openldap.org/its/index.cgi?findid=7042
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:
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.
Comment 6 Jan Vcelak 2011-09-12 17:41:34 UTC 
Resolved in:

openldap-2.4.24-5.fc15
openldap-2.4.26-3.fc16
openldap-2.4.26-3.fc17

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.
https://admin.fedoraproject.org/updates/openldap-2.4.26-3.fc16
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.
https://admin.fedoraproject.org/updates/openldap-2.4.24-5.fc15
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:
https://admin.fedoraproject.org/updates/openldap-2.4.24-5.fc15
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" ;-)
http://www.openldap.org/its/index.cgi/Incoming?id=7042#followup4

... 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!
Patrick