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

[Ryan Tandy]

Control: tag -1 upstream moreinfo
Control: severity -1 normal

Hello,

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

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