Hi, all. I'm having trouble figuring out how to allow SSL connections (using ldapsearch) to a single host with an invalid certificate. I know this can be done using TLS_REQCERT=allow (or never), but the same account also connects to multiple other hosts using certificate-based authentication, and the problem is that I can get those two configurations to work together.
To illustrate, here's the current ~/.ldaprc file for this user:
TLS_CERT /home/ldap/certs/admin.crt TLS_KEY /home/ldap/certs/admin.key TLS_REQCERT demand SASL_MECH external
That works fine for everything but this one new host. I'm not able to fix the the SSL issue on this host, so for now I need to work around it. If I replace the above ~/.ldaprc with this:
HOST server.domain.com PORT 636 TLS_REQCERT allow
Then ldapsearch works fine for this new server, but, of course, SASL/cert auth fails for everything else.
So, how do I get these to work together, with that first configuration example set as the default for all hosts *except* server.domain.com?
Here's what I've tried so far:
* Appending the configuration for server.domain.com to the existing ~/.ldaprc file - it doesn't have an effect, like the global stuff is overriding the host-specific options
* Adding the server.domain.com config to /etc/openldap/ldap.conf, but ~/.ldaprc takes precedence over this, so again it has no effect.
* 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.
* exporting both LDAPNOINIT=true and LDAPRC=.ldaprc-server, but that prevents either rc file from being sourced
* exporting LDAPNOINIT=true and calling ldapsearch with: LDAPTLS_REQCERT=allow ldapsearch -H ldaps://server.domain.com ... - this also seems to have no effect, though
I'm sure I must be missing something simple, but I'm out of ideas at this point. Would appreciate any tips or pointers.
Thanks!
Hi!
Invalid certificates are, well, invalid. The whole security model on certificates is based on certificates being valid. Beforte you try to mess with invalid certificates, please use valöid certificates. Complain if other parties provide such certificates, please complain. (I'm tired of new software being shipped with expired certificates...)
Regards, Ulrich
Jared list-389@legroom.net schrieb am 09.10.2013 um 00:41 in Nachricht
Hi, all. I'm having trouble figuring out how to allow SSL connections (using ldapsearch) to a single host with an invalid certificate. I know this can be done using TLS_REQCERT=allow (or never), but the same account also connects to multiple other hosts using certificate-based authentication, and the problem is that I can get those two configurations to work together.
To illustrate, here's the current ~/.ldaprc file for this user:
TLS_CERT /home/ldap/certs/admin.crt TLS_KEY /home/ldap/certs/admin.key TLS_REQCERT demand SASL_MECH external
That works fine for everything but this one new host. I'm not able to fix the the SSL issue on this host, so for now I need to work around it. If I replace the above ~/.ldaprc with this:
HOST server.domain.com PORT 636 TLS_REQCERT allow
Then ldapsearch works fine for this new server, but, of course, SASL/cert auth fails for everything else.
So, how do I get these to work together, with that first configuration example set as the default for all hosts *except* server.domain.com?
Here's what I've tried so far:
- Appending the configuration for server.domain.com to the existing
~/.ldaprc file - it doesn't have an effect, like the global stuff is overriding the host-specific options
- Adding the server.domain.com config to /etc/openldap/ldap.conf, but
~/.ldaprc takes precedence over this, so again it has no effect.
- 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.
- exporting both LDAPNOINIT=true and LDAPRC=.ldaprc-server, but that
prevents either rc file from being sourced
- exporting LDAPNOINIT=true and calling ldapsearch with:
LDAPTLS_REQCERT=allow ldapsearch -H ldaps://server.domain.com ... - this also seems to have no effect, though
I'm sure I must be missing something simple, but I'm out of ideas at this point. Would appreciate any tips or pointers.
Thanks!
-- Jared
expired and self-signed.
To the other responder, yes, I understand what invalid certificates mean and represent, however, as I stated in my original e-mail, I am not able to fix that, nor can I get it fixed, anytime soon. For now, I have to work around it, hence my request for assistance.
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 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?
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 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 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.
Jared 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 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?
You want to use OpenLDAP command-line tools?
Why don't you just set env var LDAPCONF to the config file you need?
You could also override certain configuration items by setting the accompanying env var.
Ciao, Michael.
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 -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 -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?
Try:
LDAPNOINIT=true LDAPTLS_REQCERT=allow ldapsearch ...
On Wed, Oct 9, 2013 at 11:52 AM, Jared 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 -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 -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> 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> 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 thatdetail.
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. >
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).
So, LDAPNOINIT, in theory, prevents it from reading ANY config files. You'll have to specify everything in a file and use LDAPRC.
BTW, LDAPRC is a basic filename that's in either the current directory or your home directory. I'd create one with a specific name, like ~/myldap.conf, then LDAPNOINIT=true LDAPRC=myldap.conf ldapsearch
See if you can tweak that myldap.conf to get it to work.
On Wed, Oct 9, 2013 at 12:30 PM, Jared list-389@legroom.net wrote:
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 whenthe
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, butit
actually reads it *in addition* to ~/.ldaprc, which I discovered by examining strace output. There may be some cases where thisbehavior 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 perfectlyfine:
> > 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 SASLcertificate-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 ofself-signed
> certs you can > > put them into trusted CA certs file. > > > > Ciao, Michael. > > > >
On 10/09/2013 01:45 PM, Michael Ströder wrote:
You want to use OpenLDAP command-line tools?
Why don't you just set env var LDAPCONF to the config file you need?
You could also override certain configuration items by setting the accompanying env var.
correct, this is using the ldapsearch command shipped with RHEL 6.4 (2.4.23-32.el6_4.1, to be specific).
As mentioned in both my original post as well as my last response to Chad, I did try setting LDAPRC to point to a separate file, but didn't have any luck with that. I did not think to try LDAPCONF, though, so thank you for that suggestion. Unfortunately, I had the same result - my ~/.ldaprc file gets sourced in addition to $LDAPCONF, and that conflicts with or overrides the settings in $LDAPCONF, so it still fails.
By the environmental variables, just to clarify, you're referring to LDAPTLS_REQCERT and the like, right? I've tried that as well, but still no luck. Chad had also suggested this, and I showed in my reply back to him what happens when I try that.
I still think the easiest and fastest solution still is to create and install another self-signed certificate, unless you are afraid the NSA can no longer decode your data ;-)
Jared list-389@legroom.net schrieb am 09.10.2013 um 16:13 in Nachricht
expired and self-signed.
To the other responder, yes, I understand what invalid certificates mean and represent, however, as I stated in my original e-mail, I am not able to fix that, nor can I get it fixed, anytime soon. For now, I have to work around it, hence my request for assistance.
-- Jared
On 10/09/2013 02:26 AM, Michael Ströder wrote:
Jared wrote:
I'm having trouble figuring out how to allow SSL connections (using ldapsearch) to a single host with an invalid certificate.
Can you please elaborate on what invalid means in your particular context?
Ciao, Michael.
openldap-technical@openldap.org
-
Chad Scott -
Jared -
Michael Ströder -
Ulrich Windl