I found the previous post of someone else who faced the same problem I'm encountering, but I did not see a posted solution:
http://www.openldap.org/lists/openldap-technical/201310/msg00084.html
In /etc/openldap/ldap.conf, TLS_REQCERT is set to 'allow'.
I would like to leave this setting, but override it for a specific invocation of ldapsearch. I have attempted to do so by setting TLS_REQCERT in ~/.ldaprc and be setting the LDAPTLS_REQCERT environment variable. Neither has worked.
Interestingly, I _HAVE_ found that I can override TLS_CACERTDIR in either of those locations.
Is this a bug?
Andy
On Wed, 30 Apr 2014, Andrew D. Arenson wrote:
I found the previous post of someone else who faced the same problem I'm encountering, but I did not see a posted solution:
http://www.openldap.org/lists/openldap-technical/201310/msg00084.html
In /etc/openldap/ldap.conf, TLS_REQCERT is set to 'allow'.
I would like to leave this setting, but override it for a specific invocation of ldapsearch. I have attempted to do so by setting TLS_REQCERT in ~/.ldaprc and be setting the LDAPTLS_REQCERT environment variable. Neither has worked.
Interestingly, I _HAVE_ found that I can override TLS_CACERTDIR in either of those locations.
Is this a bug?
Insufficient detail. Works for me with a local build of 2.4.35 and setting LDAPTLS_REQCERT to 'allow' on the command-line, ala:
LDAPTLS_REQCERT=allow ldapsearch -H ldaps://127.0.0.1 -x
with TLS_REQCERT demand
in the system ldap.conf. It also worked as expected with 'allow' in then ldap.conf and 'demand' in the env-var.
Philip Guenther
On Wed, Apr 30, 2014 at 01:26:35PM -0700, Philip Guenther wrote:
On Wed, 30 Apr 2014, Andrew D. Arenson wrote:
I found the previous post of someone else who faced the same problem I'm encountering, but I did not see a posted solution:
http://www.openldap.org/lists/openldap-technical/201310/msg00084.html
In /etc/openldap/ldap.conf, TLS_REQCERT is set to 'allow'.
I would like to leave this setting, but override it for a specific invocation of ldapsearch. I have attempted to do so by setting TLS_REQCERT in ~/.ldaprc and be setting the LDAPTLS_REQCERT environment variable. Neither has worked.
Interestingly, I _HAVE_ found that I can override TLS_CACERTDIR in either of those locations.
Is this a bug?
Insufficient detail. Works for me with a local build of 2.4.35 and setting LDAPTLS_REQCERT to 'allow' on the command-line, ala:
LDAPTLS_REQCERT=allow ldapsearch -H ldaps://127.0.0.1 -x
with TLS_REQCERT demand
in the system ldap.conf. It also worked as expected with 'allow' in then ldap.conf and 'demand' in the env-var.
Philip Guenther
Thanks. I have 2.4.23-34 installed. What other detail might be helpful?
To my chagrin, I have rechecked and found that using LDAPTLS_REQCERT actually works, despite my reporting above that it doesn't.
Strangely, however, setting TLS_REQCERT in ~/.ldaprc does _NOT_ seem to work. Does that work for you?
Andy
On Wed, 30 Apr 2014, Andrew D. Arenson wrote:
To my chagrin, I have rechecked and found that using
LDAPTLS_REQCERT actually works, despite my reporting above that it doesn't.
Heh. PEBCAK strikes again.
Strangely, however, setting TLS_REQCERT in ~/.ldaprc does _NOT_
seem to work. Does that work for you?
Yes, it does.
Thanks. I have 2.4.23-34 installed. What other detail might be
helpful?
ls -l ~/.ldaprc # to verify perms cat -vet ~/.ldaprc # to verify contents, line-endings strace -e trace=file ldapsearch .... # check for other random failures
(Obviously if your OS doesn't have strace, substitute the correct local system call trace facility, be it truss, ktrace, or whatever.)
Philip Guenther
On Wed, Apr 30, 2014 at 02:25:10PM -0700, Philip Guenther wrote:
Thanks. I have 2.4.23-34 installed. What other detail might be
helpful?
ls -l ~/.ldaprc # to verify perms cat -vet ~/.ldaprc # to verify contents, line-endings strace -e trace=file ldapsearch .... # check for other random failures
Thanks, again. Problem solved!
I had the following line in my ~/.ldaprc file:
TLS_REQCERT demand # Might try doing this stricter -- demand
My attempt to include the comment on that line was causing the problem.
Andy
openldap-technical@openldap.org