Re: failover config: servers with same DNS address and TLS, subjectAltName extension

Howard Chu <hycsymas.com> wrote:

> When you run OpenLDAP's configure script you will see:
> 
> checking OpenSSL library version (CRL checking
capability)... no
> 
> indicating that your OpenSSL library doesn't support
it. Otherwise I suppose
> you would see in your OpenSSL release notes/docs.

Yes, I discovered HAVE_OPENSSL_CRL. The problem is that this
test
validates at mine, despite OpenSSL version (0.9.7d)

configure:19757: checking OpenSSL library version (CRL
checking
capability)
configure:19791: result: yes

And then if I use TLS_CRLCHECK, LDAP operation will fail:

ldap_bind: Can't contact LDAP server (-1)
        additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed

I hope you'll agree with me that this is *very* misleading
if CRL checks
are not supposed to work with 0.9.7d. 

> You posted your email as if it was a general solution
for anybody trying to
> solve the aliased server name problem for TLS
certificates. 

Quoting myself: "here is the result of my
experiments"

I wouldn't call that a claim of being an authoritative
guide. I posted
it there with the hope it could be useful to other looking
for the piece
of information I missed. It was not perfect, but that's not
a problem,
since you and other kindly pointed out the errors. If you
don't
discourage me too much, I may even post an update with your
comments
included.

> This part of your config is not part of that general
solution, it is
> specific to your deployment. In particular, the
sasl-secprops setting is a
> global option and affects all connections, whether they
use TLS or not. As
> such, you are allowing users to use login/plain over
cleartext connections
> as well as TLS connections. You might have taken
precautions against this
> in the other parts of your slapd.conf (using the
security directive)

Yes, I have this. Is it fine? 
security        simple_bind=128

> but you didn't indicate those precautions 
> anywhere in what you posted. So you will mislead anyone
following your advice
> into leaving their servers quite vulnerable.

I hope people do some testing before rolling a copy/pasted
configuration
in production...

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz

manunetbsd.org

--On Tuesday, July 24, 2007 9:18 PM +0200 Emmanuel Dreyfus 
<manunetbsd.org> wrote:


>> but you didn't indicate those precautions
>> anywhere in what you posted. So you will mislead
anyone following your
>> advice into leaving their servers quite
vulnerable.
>
> I hope people do some testing before rolling a
copy/pasted configuration
> in production...


Experience shows they generally don't.  Your posts will
likely show up now 
in google searches by people who aren't really interested in
going and 
actually reading documentation, and/or end up in some
forsaken "how-to". :/ 
It happens often.  I periodically troll google searches of
ldap how-to's 
and ask people to either take them down or fix them,
depending on how 
incorrect they are.  Sometimes, the people are even
responsible enough to 
fix them.

--Quanah

--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and
collaboration

--On Wednesday, July 25, 2007 4:07 PM +0000 Emmanuel Dreyfus

<manunetbsd.org> wrote:

> On Wed, Jul 25, 2007 at 08:53:22AM -0700, Quanah
Gibson-Mount wrote:
>> > I hope people do some testing before rolling a
copy/pasted
>> > configuration in production...
>> Experience shows they generally don't.  Your posts
will likely show up
>> now  in google searches by people who aren't really
interested in going
>> and  actually reading documentation, and/or end up
in some forsaken
>> "how-to". :/
>
> I hope so. I have been googling for a starting point
without much
> success,  hence the desire to add some information.
Indeed iit's not
> perfect, but it's just a post in a mailing list, it's
not a FAQ entry.
> And since people point  out the mistakes in the thread,
the curious
> reader should have everything  needed at hand to
succeed.
>
> What do you prefer?
> 1) The beginner find hardly no information, gives up
after 2 days of
> failures, and will claim everywhere that OpenLDAP is
the most frustrating
> software he had to deal with

As pointed out by Howard multiple times, nearly everything
you "couldn't 
find" was actually available online, in the form of
published 
documentation, by the folks who provided the software.  The
fact that you 
went to Google *before* going to the sites that actually
distribute the 
software and reading their documentation is unfortunately
the same thing 
many other people do to.  And then they tend to complain
about the lack of 
documentation.

> 2) It finds some hints with follow-up comments and can
either screw his
> setup by just copy/pasting without a though, or read
the thread and find
> the missing pieces he needs by himself.

They'll screw up their set up, and then they'll send barages
of email 
asking why things didn't work, because they expect it to
work the first 
time, and then they'll go around claming that OpenLDAP or
some other 
software is the most frustrating software to deal with
because they get 
told to actually go read the documentation.

--Quanah


--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and
collaboration

On Wed, Jul 25, 2007 at 08:53:22AM -0700, Quanah
Gibson-Mount wrote:
> >I hope people do some testing before rolling a
copy/pasted configuration
> >in production...
> Experience shows they generally don't.  Your posts will
likely show up now 
> in google searches by people who aren't really
interested in going and 
> actually reading documentation, and/or end up in some
forsaken "how-to". :/ 

I hope so. I have been googling for a starting point without
much success, 
hence the desire to add some information. Indeed iit's not
perfect, but it's
just a post in a mailing list, it's not a FAQ entry. And
since people point 
out the mistakes in the thread, the curious reader should
have everything 
needed at hand to succeed.

What do you prefer? 
1) The beginner find hardly no information, gives up after 2
days of 
failures, and will claim everywhere that OpenLDAP is the
most frustrating 
software he had to deal with

or 

2) It finds some hints with follow-up comments and can
either screw his
setup by just copy/pasting without a though, or read the
thread and find
the missing pieces he needs by himself.

-- 
Emmanuel Dreyfus
manunetbsd.org

On Tuesday 24 July 2007 21:18, Emmanuel Dreyfus wrote:
> Howard Chu <hycsymas.com> wrote:
> > When you run OpenLDAP's configure script you will
see:
> >
> > checking OpenSSL library version (CRL checking
capability)... no
> >
> > indicating that your OpenSSL library doesn't
support it. Otherwise I
> > suppose you would see in your OpenSSL release
notes/docs.
>
> Yes, I discovered HAVE_OPENSSL_CRL. The problem is that
this test
> validates at mine, despite OpenSSL version (0.9.7d)
>
> configure:19757: checking OpenSSL library version (CRL
checking
> capability)
> configure:19791: result: yes
>
> And then if I use TLS_CRLCHECK, LDAP operation will
fail:
>
> ldap_bind: Can't contact LDAP server (-1)
>         additional info: error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed
>
> I hope you'll agree with me that this is *very*
misleading if CRL checks
> are not supposed to work with 0.9.7d.

They should work with 0.9.7d. IIRC that was the version I
used when 
implementing CRL support. 
Note: As stated in the man-pages (ldap.conf(5) and
slapd.conf(5)), when you 
want to use CRLs you have to specify a CACERTDIR. That
directory has to be 
correctly hashed (using c_rehash).

-- 
Ralf

On Jul 26, 2007, at 1:28 AM, Ralf Haferkamp wrote:

[... re CRL checks ...]

> They should work with 0.9.7d. IIRC that was the version
I used when
> implementing CRL support.

Right.

> Note: As stated in the man-pages (ldap.conf(5) and
slapd.conf(5)),  
> when you
> want to use CRLs you have to specify a CACERTDIR. That
directory  
> has to be
> correctly hashed (using c_rehash).

I don't use CACERTDIR, I put the CRL in the CA certificate.

That works, but there's a maintenance problem.  Our CRLs
expire, fairly
quickly, and that breaks certificate verification, so once
we have a  
CRL,
we have to keep it up to date whether we care about it or
not.  There
doesn't seem to be any way to reload a CRL (OpenSSL bug
1424, Nov 8  
2006),
so we have to restart slapd for each update.  Does the
CACERTDIR  
approach
avoid this problem?

	Donn Cave, donnu.washington.edu

Am Do 26 Jul 2007 18:39:22 CEST schrieb Donn Cave
<donnu.washington.edu>:

> On Jul 26, 2007, at 1:28 AM, Ralf Haferkamp wrote:
>
> [... re CRL checks ...]
>
>> They should work with 0.9.7d. IIRC that was the
version I used when
>> implementing CRL support.
>
> Right.
>
>> Note: As stated in the man-pages (ldap.conf(5) and
slapd.conf(5)), when you
>> want to use CRLs you have to specify a CACERTDIR.
That directory has to be
>> correctly hashed (using c_rehash).
>
> I don't use CACERTDIR, I put the CRL in the CA
certificate.
Ah, ok that should work as well.

> That works, but there's a maintenance problem.  Our
CRLs expire, fairly
> quickly, and that breaks certificate verification, so
once we have a CRL,
> we have to keep it up to date whether we care about it
or not.  There
> doesn't seem to be any way to reload a CRL (OpenSSL bug
1424, Nov 8 2006),
> so we have to restart slapd for each update.  Does the
CACERTDIR approach
> avoid this problem?
No, unfortunately not.

-- 
Ralf