I had tried that as well.  You seem to be going down the line of thought
I had last night.  :-)  Not sure why, but I can't get it to work at all
with LDAPNOINIT=true whether the ~/.ldaprc file exists or not.
Regardless of whatever other options I throw at it, I always get:

$ LDAPNOINIT=true LDAPTLS_REQCERT=allow ldapsearch -LLL -x -H
ldaps://server.domain.com -D "<SNIP>" -w <SNIP> -b dc=domain,dc=com uid=user

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

I also tried this variant, with TLS_REQCERT=allow defined in a custom rc
file:

$ LDAPNOINIT=true LDAPRC=.ldaprc-server ldapsearch -LLL -x -H
ldaps://server.domain.com -D "<SNIP>" -w <SNIP> -b dc=domain,dc=com uid=user

but, LDAPNOINIT prevents the custom file from being sourced as well
(which, in this case, is probably to be expected).

--
Jared

On 10/09/2013 02:01 PM, Chad Scott wrote:
> Try:
>
> LDAPNOINIT=true LDAPTLS_REQCERT=allow ldapsearch ...
>
>
> On Wed, Oct 9, 2013 at 11:52 AM, Jared <list-389@legroom.net

> <mailto:list-389@legroom.net>> wrote:
>
>     Hi, Chad.  Thanks for the suggestions.
>
>     I actually did try your LDAPTLS_REQCERT=allow suggestion, but when the
>     existing ~/.ldaprc is in place (with the TLS_REQCERT=demand line), that
>     option seems to be ignored for some reason.  I don't know why.
>
>     To illustrate:
>
>     $ cat ~/.ldaprc
>     TLS_CERT /home/ldap/certs/admin.crt
>     TLS_KEY /home/ldap/certs/admin.key
>     TLS_REQCERT demand
>     SASL_MECH external
>
>     $ LDAPTLS_REQCERT=allow ldapsearch -LLL -x -H

>     ldaps://server.autozone.com <http://server.autozone.com> -D "<SNIP>"

>     -w <SNIP> -b dc=domain,dc=com
>     uid=user
>     ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>
>     $ mv ~/.ldaprc ~/.ldaprc-old
>
>     $ LDAPTLS_REQCERT=allow ldapsearch -LLL -x -H

>     ldaps://server.autozone.com <http://server.autozone.com> -D "<SNIP>"

>     -w <SNIP> -b dc=domain,dc=com
>     uid=user
>     dn: uid=user,ou=people,dc=domain,dc=com
>     uid: user
>     <SNIP>
>
>     It seems like the ~/.ldaprc file is overriding what I specify on the
>     command line, but as I mentioned before, I *have* to have that global
>     configuration there for all of the other LDAP server this account
>     interacts with.
>
>     Likewise, I did try messing with the LDAPRC variable.  I actually
>     mentioned that in my original post:
>
>     * Creating a separate ~/.ldaprc-server file and exporting
>     LDAPRC=.ldaprc-server - in this case, both ~/.ldaprc AND
>     ~/.ldaprc-server are sourced (found using strace), so again my
>     host-specific settings are ignored.
>
>     I'd consider that a bug in ldapsearch - if I'm explicitly defining
>     LDAPRC, I'd expect it to ready that file *instead* of ~/.ldaprc, but it
>     actually reads it *in addition* to ~/.ldaprc, which I discovered by
>     examining strace output.  There may be some cases where this behavior is
>     desired, but in this case, it causes my global configuration to
>     (apparently) again take precedence, overriding the TLS_REQCERT=allow
>     setting.
>
>     Any other suggestions?
>
>     --
>     Jared
>
>     On 10/09/2013 01:26 PM, Chad Scott wrote:
>     > Set environment variables.
>     >
>     > export LDAPTLS_REQCERT=allow
>     >
>     > or
>     >
>     > LDAPTLS_REQCERT=allow ldapsearch ...
>     >
>     > If neither of those work, specify a specific LDAPRC with:
>     >
>     > export LDAPRC=somefile.conf
>     >
>     > or
>     >
>     > LDAPRC=somefile.conf ldapsearch ...
>     >
>     >
>     > On Wed, Oct 9, 2013 at 11:12 AM, Jared <list-389@legroom.net
>     <mailto:list-389@legroom.net>

>     > <mailto:list-389@legroom.net <mailto:list-389@legroom.net>>> wrote:
>     >
>     >     but I can.  As I mentioned in my original post, adding this to
>     ~/.ldaprc
>     >     or /etc/openldap/ldap.conf makes ldapsearch work perfectly fine:
>     >
>     >     HOST server.domain.com <http://server.domain.com>
>     <http://server.domain.com>
>     >     PORT 636
>     >     TLS_REQCERT allow
>     >
>     >     The problem is with applying this configuration to the one
>     host while
>     >     still setting my default configuration for SASL certificate-based
>     >     authentication to everything else.  How do I do that?
>     >
>     >     or, to ask the question differently, forget the fact that I'm
>     dealing
>     >     with an invalid cert.  There's no need to to get hung up on
>     that detail.
>     >      I have one ldaprc configuration that I need to define for a
>     host, and a
>     >     default ldaprc configuration I need to define for all other
>     hosts.  How
>     >     do I make them work together?
>     >
>     >     --
>     >     Jared
>     >
>     >     On 10/09/2013 01:06 PM, Michael Ströder wrote:
>     >     > Jared wrote:
>     >     >> expired and self-signed.
>     >     >
>     >     > You cannot work around expired certs. But in case of self-signed
>     >     certs you can
>     >     > put them into trusted CA certs file.
>     >     >
>     >     > Ciao, Michael.
>     >     >
>     >
>     >
>
>