Full_Name: Jan Vcelak Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20110912-syncrepl-allow-unsetting-of-tls-options.patch Submission from: (NULL) (209.132.186.34) Hello, I'm just passing a patch submitted to our bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=734187 To sum it up: If tls_cert/tls_key syncrepl options are not specified, server setting is inherited and used. According to various reports on the Internet, this is a feature, not a bug. However it forces a replica to use a client certificate for authentication, because the tls_cert and tls_key options can not be disabled. The patch allows tls_* options to be disabled, like this: "tls_cert=" Without the patch, "file not found" error will occur. The patch is written by the submitter of the bug report - Patrick Monnerat (pm at datasphere dot ch). Jan
jvcelak@redhat.com wrote: > Full_Name: Jan Vcelak > Version: master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20110912-syncrepl-allow-unsetting-of-tls-options.patch > Submission from: (NULL) (209.132.186.34) > > > Hello, > > I'm just passing a patch submitted to our bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=734187 > > To sum it up: If tls_cert/tls_key syncrepl options are not specified, server > setting is inherited and used. According to various reports on the Internet, > this is a feature, not a bug. Relying on hearsay "According to various reports on the Internet" is a stupid way to get information, particularly when it's already documented in the slapd.conf(5) and slapd-config(5) manpages. > However it forces a replica to use a client > certificate for authentication, because the tls_cert and tls_key options can not > be disabled. > > The patch allows tls_* options to be disabled, like this: "tls_cert=" > Without the patch, "file not found" error will occur. > The patch is written by the submitter of the bug report - Patrick Monnerat (pm > at datasphere dot ch). Thanks for passing along the report, but I'm not convinced this is a legitimate issue. Servers that trust each other for replication should accept each other's TLS certificates. As I see it, if their certs aren't working in this configuration then their certificates were created with the wrong usage flags, and this is not an OpenLDAP issue. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Monday 12 September 2011 19:00:08, Howard Chu wrote: > Thanks for passing along the report, but I'm not convinced this is a > legitimate issue. Servers that trust each other for replication should > accept each other's TLS certificates. As I see it, if their certs aren't > working in this configuration then their certificates were created with > the wrong usage flags, and this is not an OpenLDAP issue. You are definitely right. But disabling the options still might be useful for some people. Including the author of the patch. I think it is a very simple change which adds some extra bonus to current functionality. Nothing critical and no regressions are likely. It would be great, if you could include the patch even if you do not absolutely agree with disabling the client certificate authentication for replication. -- Jan Včelák Base Operating Systems Brno Red Hat Inc.
I note that third-party patch submissions cannot be accepted per our IPR policies. The original author is required to submit their own patches. -- Kurt
changed notes
Hi, I am the author of the patch at: ftp://ftp.openldap.org/incoming/jvcelak-20110912-syncrepl-allow-unsetting-of-tls-options.patch and I want to argue in favor of it: 1) In a configuration using a simple bind to authenticate a client, you have no choice but using ldaps to protect password sniffing: this requires a SERVER certificate only. 2) Since primary and replicated servers can have their role reversed (i.e.: after failure and/or recovery of the former primary server), the configurations should be kept as symmetric as possible (except for syncrepl) in order to speed-up switch: SSL in both servers should thus have the same configuration. 3) syncrepl then forces SSL to use a client certificate rather than a simple bind for authentication: this implies "normal" clients will also need a certificate... we are then in a situation lying very far from using ldaps for encryption only :-( 4) Using separate server and client certificates within a server, although safer, does not resolve my problem. For the above reason, I would really like to see my patch included in openldap code, or at least an equivalent solution. Because "third-party patch submissions cannot be accepted per our IPR policies. The original author is required to submit their own patches.", do you need me to re-submit it ? Thanks in advance for your reply. Regards, Patrick Monnerat DATASPHERE S.A. 16, chemin des Aulx CH-1228 Plan-les-Ouates (GE)
moved from Incoming to Software Bugs
Hi Patrick, What we need is for you to simply reply to this ITS with your IPR statement, and the patch attached. This will allow us to include it. IPR guidelines are here: <https://www.openldap.org/devel/contributing.html#notice> Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
On 10/19/2017 05:07 PM, Quanah Gibson-Mount wrote: > Hi Patrick, Hi Quanah, Thanks for your directives and future action. > > What we need is for you to simply reply to this ITS with your IPR > statement, and the patch attached. This will allow us to include it. > Here they are: I, Patrick Monnerat, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. Patrick
changed notes changed state Open to Test
changed notes changed state Test to Release
On Sat, Oct 21, 2017 at 03:50:48PM +0000, patrick@monnerat.net wrote: > Hi Quanah, > Thanks for your directives and future action. Hi Patrick, thank you for your patch, it has now been pushed to master (0f9afae02d9425e54f070ecd5ea8b954115e092b) and will also be part (e5f945bab40482e2045fede3fbe9a04210808a93) of the upcoming 2.4.48 release. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Fixed in master Fixed in RE24 (2.4.48)
changed notes changed state Release to Closed