[Pkg-openldap-devel] Bug#807922: slapd: Unable to use olcTLSVerifyClient

Albert Shih Albert.Shih at obspm.fr
Mon Jan 4 16:39:24 UTC 2016


 Le 27/12/2015 à 21:10:06-0800, Ryan Tandy a écrit
> Control: tag -1 upstream moreinfo Control: severity -1 normal
>
Hi,

>
> Thank you for the report, and sorry for not answering sooner.

No problem.


>
> On Mon, Dec 14, 2015 at 03:05:22PM +0100, Obspm wrote:
> >>From a fresh install (the server is a virtual machine with
> >>VirtualBox), after basic configuration of slapd, without any
> >>configuration other than those make by apt-get, with no special data
> >>I can add this piece of ldif
> >
> >	dn: cn=config changeType: modify
> > 	add: olcTLSVerifyClient
> >	olcTLSVerifyClient: never -
> >
> >I always got a
> >
> >root at debian:~# ldapmodify -Y EXTERNAL -H ldapi:/// -f toto.ldif
> >SASL/EXTERNAL authentication started SASL username:
> >gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0
> >modifying entry "cn=config" ldap_modify: Server is unwilling to
> >perform (53)
>
> At the moment, I think this behaviour is intentional and by design.
>
> First, I would note that this only happens when you haven't performed
> the minimal TLS configuration yet:
>
> http://sources.debian.net/src/openldap/2.4.40%2Bdfsg-1%2Bdeb8u1/libraries/libldap/tls2.c/#L199-L202
>
> In this case, "unwilling to perform" means that the change can't be
> applied and take effect immediately, because TLS isn't even active
> yet.  After you configure a server certificate or CA certificate, then
> you can start setting TLS options.
>
> You could argue that the change should be accepted and committed, as
> if it had been done offline, and saved for when TLS is next started.
> (I say "change" here intentionally, even though the value in your
> example is the same as the default.)
>
> There is room on either side, to argue that a more informative error
> message could be returned along with the error code, or that there is
> precedent for cn=config changes that are accepted but not applied
> until some subsystem, or slapd itself, is restarted. I don't have any
> particular opinion on any of this, and would rather not argue with
> upstream about design choices.
>
> I am not forwarding this upstream right now, but I'd be willing to, if
> you can say a few more words about how you think this should behave
> and why. Alternatively you could open a report yourself at
> http://openldap.org/its; if you do that, please link the report here.
>
> thanks, Ryan

In fact I find the « problem ». I don't known if it's really a bug, a
« not_very_user_friendly_feature » or thing like that.

They are two points :

  1/ I need to add those olc* in a specific order, if I don't I get those
  insult (unwilling to perform)

  2/ If those files (certificat-private-key, ca-chain, certificat) are not
  readeable WHEN the daemon start, changing the right/owner (by
  chmod/chown) don't change anything. That's mean if when the slapd daemon
  start, I got the wrong owner of the private key, I need to restart the
  daemon AFTER changing the owner.

Mixing those two constraint make you crazy....especially when, like me, you
use puppet to install everything.

Anyway thanks you very much for answering me and maintaining those package.

Regards

JAS

--
Albert SHIH
DIO bâtiment 15
Observatoire de Paris
5 Place Jules Janssen
92195 Meudon Cedex
France
Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71
xmpp: jas at obspm.fr
Heure local/Local time:
lun 4 jan 2016 17:32:54 CET



More information about the Pkg-openldap-devel mailing list