9:28 a.m.
I was recently asked if we could use ssl client certs as a 2nd form
of authentication with OpenLDAP and didn't know for sure. Is it
possible to have OpenLDAP require both a DN/password pair *and* a client
ssl cert?
Just to see if I could make any form of client cert authentication
work, I took a test-bed instance of OpenLDAP and added this line to
slapd.conf:
TLSVerifyClient allow
Then I created a self-signed ssl cert, converted it to a .der binary
file, then added it to an LDAP record's userCertificate attribute with this:
dn: <my-dn>
changetype: modify
add: userCertificate;binary
userCertificate;binary:< file:///tmp/ldapclient.bin
Then I found my ldap client of choice doesn't seem to have an option
to authenticate via client certs, and didn't see any command line
options for ldapsearch for specifying a client ssl cert/key pair. So I
edited ~/.ldaprc and added:
BINDDN <my-dn>
TLS_REQCERT demand
TLS_CERT /tmp/ldapclient.crt
TLS_KEY /tmp/ldapclient.key
But when I run ldapsearch -x with no -D and -W options, it's clearly
still just binding anonymously. When I run ldapsearch -x with a -D and
no -W option it says I can't bind without a password. :-) So... I'm
clearly missing something here.
How do I get ldapsearch to try to authenticate with the SSL cert?
Or is it possibly trying but failing because slapd can't validate the
self-signed client cert I made? It's definitely finding and using my
.ldaprc file because I can change BASE, PORT, and HOST settings in there
and don't have to specify 'em on the command line afterwards, but as
near as I can tell it's not using the client cert.
Brent
10 a.m.
Brent Bice wrote:
I was recently asked if we could use ssl client certs as a 2nd
form of
authentication with OpenLDAP and didn't know for sure. Is it possible to have
OpenLDAP require both a DN/password pair *and* a client ssl cert?
Regarding client certs you have two options:
1. Let the client use a client cert and SASL/EXTERNAL to bind to the LDAP
server. Then use authz-regexp in the server's configuration to map the client
cert to a authz-DN - ideally an existing entry. Depending on how your client
certs are used you could consider this to be 2-factor authc, e.g. in case of
client cert's key is stored on a smartcard with separate PIN.
2. Let the client use a client cert and simple bind with DN/password sent to
the LDAP server. AFAIK you can't enforce that the client cert matches the
bind-DN though. So regarding this as real 2-factor authc is somewhat questionable.
In any case you have to set up your server to correctly validate the client
certs against a locally configured trusted CA cert.
Ciao, Michael.
10:07 a.m.
Brent Bice wrote:
I was recently asked if we could use ssl client certs as a 2nd
form
of authentication with OpenLDAP and didn't know for sure. Is it
possible to have OpenLDAP require both a DN/password pair *and* a client
ssl cert?
You can make the server require a client cert, but it won't use the
certificate identity for anything unless you Bind with SASL/EXTERNAL.
http://www.openldap.org/doc/admin24/sasl.html#EXTERNAL
And naturally, if you're using SASL, then the DN/password pair is ignored.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10:53 a.m.
Howard Chu wrote:
Brent Bice wrote:
> I was recently asked if we could use ssl client certs as a 2nd form
> of authentication with OpenLDAP and didn't know for sure. Is it
> possible to have OpenLDAP require both a DN/password pair *and* a client
> ssl cert?
You can make the server require a client cert, but it won't use the
certificate identity for anything unless you Bind with SASL/EXTERNAL.
http://www.openldap.org/doc/admin24/sasl.html#EXTERNAL
And naturally, if you're using SASL, then the DN/password pair is ignored.
BTW:
In case of client certs the cert's subject-DN is the authc-DN which can be
directly used in authz-regexp which very much ties the mapping to subject-DN
conventions of the PKI.
But in some cases it would be very handy to map a distinct client cert to a
authz-DN by issuer-DN/serial or even by fingerprint. One use-case is cert
pinning of client certs and revocation checking done off-line.
Should I file an ITS for that?
Ciao, Michael.
11:12 a.m.
Michael Ströder wrote:
Howard Chu wrote:
> Brent Bice wrote:
>> I was recently asked if we could use ssl client certs as a 2nd form
>> of authentication with OpenLDAP and didn't know for sure. Is it
>> possible to have OpenLDAP require both a DN/password pair *and* a client
>> ssl cert?
>
> You can make the server require a client cert, but it won't use the
> certificate identity for anything unless you Bind with SASL/EXTERNAL.
>
> http://www.openldap.org/doc/admin24/sasl.html#EXTERNAL
>
> And naturally, if you're using SASL, then the DN/password pair is ignored.
BTW:
In case of client certs the cert's subject-DN is the authc-DN which can be
directly used in authz-regexp which very much ties the mapping to subject-DN
conventions of the PKI.
But in some cases it would be very handy to map a distinct client cert to a
authz-DN by issuer-DN/serial or even by fingerprint. One use-case is cert
pinning of client certs and revocation checking done off-line.
Should I file an ITS for that?
I would reject such an ITS. Cert-pinning is an issue for clients that have a
very large collection of trusted CAs. The Admin Guide clearly states that
servers should only trust a single CA - the CA that signed its own certs and
the certs of its clients. In that case, no one else can issue a valid cert
with the same subjectDN.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11:26 a.m.
Howard Chu wrote:
Michael Ströder wrote:
> BTW:
>
> In case of client certs the cert's subject-DN is the authc-DN which can be
> directly used in authz-regexp which very much ties the mapping to subject-DN
> conventions of the PKI.
>
> But in some cases it would be very handy to map a distinct client cert to a
> authz-DN by issuer-DN/serial or even by fingerprint. One use-case is cert
> pinning of client certs and revocation checking done off-line.
>
> Should I file an ITS for that?
I would reject such an ITS. Cert-pinning is an issue for clients that have a
very large collection of trusted CAs. The Admin Guide clearly states that
servers should only trust a single CA - the CA that signed its own certs and
the certs of its clients. In that case, no one else can issue a valid cert
with the same subjectDN.
Unfortunately it's not that easy:
Consider a (somewhat broken) "official" CA, which you definitely cannot avoid
or fix and which issues client certs with non-unique subject-DNs. In this case
one has to choose a certain client cert e.g. by issuer-DN/serial for the mapping.
Also consider that you want to off-load revocation checking of client certs to
a external process for better performance. In this case you also need to
distinguish client certs by some more information than just a subject-DN.
Furthermore it's really not unusal to have several CAs which issue client
certs for different purposes. So IMHO it should be possible to map client
certs by a certain CA only to a certain subset of authz-DNs.
Anyway I always felt that using directly the subject-DN is not consistent with
the usual "<pattern>,cn=external,cn=auth" used for SASL/EXTERNAL.
Other server implementations implement client cert to authz-DN mappings by
cert matching which is really handy in some cases.
Ciao, Michael.
11:59 p.m.
New subject: Antw: Re: OpenLDAP with ssl client certs
>> Michael Ströder<michael(a)stroeder.com> schrieb am
01.11.2013 um 19:26 in
Nachricht <5273F248.4030101(a)stroeder.com>:
Howard Chu wrote:
> Michael Ströder wrote:
>> BTW:
>>
>> In case of client certs the cert's subject-DN is the authc-DN which can
be
>> directly used in authz-regexp which very much ties the
mapping to
subject-DN
>> conventions of the PKI.
>>
>> But in some cases it would be very handy to map a distinct client cert to
a
>> authz-DN by issuer-DN/serial or even by fingerprint. One
use-case is
cert
>> pinning of client certs and revocation checking done
off-line.
>>
>> Should I file an ITS for that?
>
> I would reject such an ITS. Cert-pinning is an issue for clients that have
a
> very large collection of trusted CAs. The Admin Guide clearly
states that
> servers should only trust a single CA - the CA that signed its own certs
and
> the certs of its clients. In that case, no one else can issue a
valid cert
> with the same subjectDN.
Unfortunately it's not that easy:
Consider a (somewhat broken) "official" CA, which you definitely cannot
avoid
or fix and which issues client certs with non-unique subject-DNs. In this
case
one has to choose a certain client cert e.g. by issuer-DN/serial for the
mapping.
CAs either accept the subject name in the certification request, or they deny
it, but they never change it.
Also consider that you want to off-load revocation checking of client certs
to
a external process for better performance. In this case you also need to
distinguish client certs by some more information than just a subject-DN.
"you" is the process that handles CRLs. That process should be able to do it
properly.
Furthermore it's really not unusal to have several CAs which issue client
certs for different purposes. So IMHO it should be possible to map client
certs by a certain CA only to a certain subset of authz-DNs.
That's also wrong: You don't have to observe the issuing CA, but the
certificate's attributes, like "X509v3 Key Usage".
Anyway I always felt that using directly the subject-DN is not consistent
with
the usual "<pattern>,cn=external,cn=auth" used for SASL/EXTERNAL.
Other server implementations implement client cert to authz-DN mappings by
cert matching which is really handy in some cases.
Ciao, Michael.
12:25 a.m.
Ulrich Windl wrote:
>>> Michael Ströder<michael(a)stroeder.com> schrieb am
01.11.2013 um 19:26 in
> Unfortunately it's not that easy:
>
> Consider a (somewhat broken) "official" CA, which you definitely cannot
> avoid
> or fix and which issues client certs with non-unique subject-DNs. In this
> case
> one has to choose a certain client cert e.g. by issuer-DN/serial for the
> mapping.
CAs either accept the subject name in the certification request, or they deny
it, but they never change it.
Not true and also not relevant here.
> Also consider that you want to off-load revocation checking of
client certs
> to
> a external process for better performance. In this case you also need to
> distinguish client certs by some more information than just a subject-DN.
"you" is the process that handles CRLs. That process should be able to do it
properly.
What exactly do you want to say?
> Furthermore it's really not unusal to have several CAs which
issue client
> certs for different purposes. So IMHO it should be possible to map client
> certs by a certain CA only to a certain subset of authz-DNs.
That's also wrong: You don't have to observe the issuing CA, but the
certificate's attributes, like "X509v3 Key Usage".
Well, I'm not new to PKI but I don't get what you say.
I don't want to "observe the CA".
I just want to make sure that client certs issued by CA1 gets mapped to
certain authz-DNs (server objects in my case) and others issued by CA2 gets
mapped to other authz-DNs.
Did you really understand what I wrote?
Ciao, Michael.
11:43 a.m.
On 11/01/2013 12:12 PM, Howard Chu wrote:
I would reject such an ITS. Cert-pinning is an issue for clients
that
have a very large collection of trusted CAs. The Admin Guide clearly
states that servers should only trust a single CA - the CA that signed
its own certs and the certs of its clients. In that case, no one else
can issue a valid cert with the same subjectDN.
Thanks to everyone for their comments. Greatly appreciated and
confirmed some of my suspicions about trying to use certs as an actual
2nd factor.
So, was I right in trying to use ~/.ldaprc to try to force
ldapsearch (for instance) to use a cert for authentication? Running a
sniffer and looking at the traffic, it doesn't look like ldapsearch is
ever doing anything beyond an anonymous bind unless I specify -D and -W
in which case it's binding and authenticating as normal rather than
using a cert.
I think the notion of using a client cert as a 2nd factor will get
dropped (at least for now - grin) but my curiosity is piqued enough that
I probably will still tinker with getting slapd to validate a client
cert (just for my own edjimication) and want to be sure I'm actually
correctly getting the client to use the client cert. :-)
Brent
12:13 p.m.
Brent Bice wrote:
So, was I right in trying to use ~/.ldaprc to try to force
ldapsearch (for
instance) to use a cert for authentication? Running a sniffer and looking at
the traffic, it doesn't look like ldapsearch is ever doing anything beyond an
anonymous bind unless I specify -D and -W in which case it's binding and
authenticating as normal rather than using a cert.
Use command-line option -Y EXTERNAL to make the tools send SASL/EXTERNAL bind
as said before. Otherwise at LDAP level only simple bind or even anon bind
gets used even if you used client cert at TLS level.
Then in your slapd.conf something like this:
# Cert-based authc-DN
authz-regexp
"(.+)"
"ldap:///dc=example,dc=com??sub?(&(objectClass=pkiUser)(seeAlso=$1))"
Then you have to store the client cert's subject DN in attribute 'seeAlso' in
LDAP DN string representation (openssl x509 -nameopt rfc2253).
I think the notion of using a client cert as a 2nd factor will get
dropped
Again:
The 2nd factor depends on whether you have smartcards at the client side or not.
Ciao, Michael.
11:54 p.m.
New subject: Antw: Re: OpenLDAP with ssl client certs
>> Howard Chu <hyc(a)symas.com> schrieb am 01.11.2013 um
19:12 in Nachricht
<5273EF18.3070700(a)symas.com>:
Michael Ströder wrote:
> Howard Chu wrote:
>> Brent Bice wrote:
>>> I was recently asked if we could use ssl client certs as a 2nd
form
>>> of authentication with OpenLDAP and didn't know for
sure. Is it
>>> possible to have OpenLDAP require both a DN/password pair *and* a client
>>> ssl cert?
>>
>> You can make the server require a client cert, but it won't use the
>> certificate identity for anything unless you Bind with SASL/EXTERNAL.
>>
>> http://www.openldap.org/doc/admin24/sasl.html#EXTERNAL
>>
>> And naturally, if you're using SASL, then the DN/password pair is
ignored.
>
> BTW:
>
> In case of client certs the cert's subject-DN is the authc-DN which can be
> directly used in authz-regexp which very much ties the mapping to
subject-DN
> conventions of the PKI.
>
> But in some cases it would be very handy to map a distinct client cert to
a
> authz-DN by issuer-DN/serial or even by fingerprint. One
use-case is cert
> pinning of client certs and revocation checking done off-line.
>
> Should I file an ITS for that?
I would reject such an ITS. Cert-pinning is an issue for clients that have a
very large collection of trusted CAs. The Admin Guide clearly states that
servers should only trust a single CA - the CA that signed its own certs and
Sorry, but if you insist on that, you didn't understand the concept: Any
certificate signed (transitively) by a root CA is valid. There are no
distinctions between more or less valid certificates; they are either valid or
invalid. Even if you talk about a single CA, what do you mean? A name of a CA,
or one specific certificate of a CA? Over time one CA may have more than one
certificate.
Please don't set up arbitrary restrictions or recommendations!
Regards,
Ulrich
the certs of its clients. In that case, no one else can issue a valid cert
with the same subjectDN.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12:38 p.m.
New subject: Antw: Re: OpenLDAP with ssl client certs
--On Monday, November 04, 2013 8:54 AM +0100 Ulrich Windl
<Ulrich.Windl(a)rz.uni-regensburg.de> wrote:
Sorry, but if you insist on that, you didn't understand the
concept: Any
certificate signed (transitively) by a root CA is valid. There are no
distinctions between more or less valid certificates; they are either
valid or invalid. Even if you talk about a single CA, what do you mean? A
name of a CA, or one specific certificate of a CA? Over time one CA may
have more than one certificate.
Sorry, you are wrong. I suggest you think about this for a while until you
realize why blindly trusting any cert issues by any CA is not a good idea.
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
12:05 a.m.
New subject: Antw: Re: OpenLDAP with ssl client certs
Quanah Gibson-Mount wrote:
--On Monday, November 04, 2013 8:54 AM +0100 Ulrich Windl
<Ulrich.Windl(a)rz.uni-regensburg.de> wrote:
> Sorry, but if you insist on that, you didn't understand the concept: Any
> certificate signed (transitively) by a root CA is valid. There are no
> distinctions between more or less valid certificates; they are either
> valid or invalid. Even if you talk about a single CA, what do you mean? A
> name of a CA, or one specific certificate of a CA? Over time one CA may
> have more than one certificate.
Sorry, you are wrong. I suggest you think about this for a while until you
realize why blindly trusting any cert issues by any CA is not a good idea.
=> Cert pinning when validating client certs in the server also makes sense.
Ciao, Michael.
3500
days inactive
3504
days old
openldap-technical@openldap.org
12 comments
5 participants
participants (5)
-
Brent Bice -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount -
Ulrich Windl