[Date Prev][Date Next]
Re: Self-signed CA certificates in 2.1.8
Try putting the CA of the self-signed cert into your slapd.conf, with
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
Brandon IT Consulting
On Monday 25 November 2002 12:17, firstname.lastname@example.org wrote:
> On 08 Nov 2002 10:42:56 +0100 Tony Earnshaw <email@example.com> 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.