Re: Self-signed CA certificates in 2.1.8

[Stephen Brandon <stephen@brandonitconsulting.co.uk>]

Try putting the CA of the self-signed cert into your slapd.conf, with 
TLSCACertificateFile  <filename>

I am not an expert with doing these things, but when using back-ldap to 
connect to a server with a self-signed cert, that's what I had to do in your 
situation.

Cheers,
Stephen Brandon
Brandon IT Consulting


On Monday 25 November 2002 12:17, jpatokal@iki.fi wrote:
> On 08 Nov 2002 10:42:56 +0100 Tony Earnshaw <tonni@billy.demon.nl> wrote:
> > tor, 2002-11-07 kl. 13:31 skrev Jani Patokallio:
> > > I'm getting strange errors about self-signed certificates in OpenLDAP
> > > 2.1.8 with OpenSSL 0.9.6b-28...
> >
> > Jani, I think, you'll find it's your server public cert that isn't
> > being accepted. TLS certificate verification: depth: 1, err: 19 is
> > o.k.(18 and 19 are o.k.), that it's reported as self-signed means that
> > there's no signing hierarchy stemming from a recognized authority.
>
> Doesn't depth 1 means that it's the *second* certificate in the chain,
> ie. the CA certificate, that's being rejected?  We tried feeding
> OpenLDAP a self-signed server certificate (ie. signed by the server
> itself, no CA involved), and OpenLDAP gave the same error with depth 0.
>
> > In solving this one, make doubly sure that the SUBJECT of the server
> > public key certificate agrees with the fully qualified name of your
> > server, which must refer back to the IP number of the machine the ldap
> > server is running on and agree with whatever method you use to resolve
> > that IP number (whether that be /etc/hosts or DNS.)
>
> So we rebuilt the thing from scratch, with CN=ldap.labra.fi in the
> certificate's Subject field, and the IPs and machine names hardcoded
> in the /etc/hosts file on both machines.  Still no go -- we're getting
> precisely the same error, depth 1 err 19.  An Ethereal snoop of
> the traffic seems to indicate that the names are being resolved
> just fine.
>
> Frankly, I'm at my wits' end here; looks like we'll have to hack
> the code to ignore the error for time being, but this is obviously
> not a long-term solution.  Could OpenSSL be the issue here?
> Our certificates are generated on the same machine with the same
> version though, so it seems unlikely...  the error is, according
> to libldap/tls.c, originating from OpenSSL though.
>
> Cheers,
> -j.