[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: slapd[5100]: connection_read(12): TLS accept error error=-1



On Fri, May 27, 2005 at 09:17:39AM +0200, Ragnar Wisløff wrote:
> fredag 27. mai 2005, 08:25, skrev Geert Stappers:
> > On Thu, May 26, 2005 at 11:45:48PM +0200, Finn-Arne Johansen wrote:
> > > Geert Stappers wrote:
> > > > Hello,
> >
> >  <snip/>
> > > > May 26 21:11:17 tw89 slapd[5100]: connection_read(12): TLS accept error error=-1 id=20, closing
 <snip/>
> > > >
> > > > My questions are
> > > >
> > > >  Why do I get the TLS accept error ?
> > > >
> > > >  How to get more debug information when the loglevel is allready 16383
> > > > ?
> > > >
> > > >  Where to search for more clues?
> > >
> > > Have you told the clients to ignore the SSL certificate ?
> >
> > Sorry, not that I know. I use "plain" ldapsearch from the ldap-utils
> > package.
> >
> > The manaul page tells about SASL voodoo, but nothing about SSL. What should
> > I do at clients side to ignore or to honour the SSL certificate?
> >
> >
> > While being clueless, is the gut feeling is that the cullprit is at
> > serverside. Why should I search at client side?
> 
> Add to /etc/ldap/ldap.conf 
> 
> TLS_REQCERT allow
> 
> for each client you want to accept a self-signed certificate. If you want 
> nothing to do with certificates at all, then use 
> 
> TLS_REQCERT never
> 
> man 5 ldap.conf gives you all the gory details.

That did bring 
--- slapd.conf  2005/05/27 09:02:44     1.12
+++ slapd.conf  2005/05/27 17:23:06     1.13
@@ -136,10 +136,12 @@
 #include         /etc/ldap/ldap-access


-TLSCipherSuite          HIGH:MEDIUM:SSLv2
-TLSCertificateFile      /etc/ldap/ssl/slapd.pem
-TLSCertificateKeyFile   /etc/ldap/ssl/slapd.pem
-TLSCACertificateFile    /etc/ldap/ssl/slapd.pem
+TLS_CACERT       /etc/ldap/ssl/slapd.pem
+TLS_CACERTDIR    /etc/ldap/ssl
+TLS_CERT         /etc/ldap/ssl/slapd.pem
+TLS_KEY          /etc/ldap/ssl/slapd.pem
+TLS_REQCERT never
+

 #######################################################################
 # Specific Directives for database #2, of type 'other' (can be bdb
 # too):

The problem presists ...

My current clue is 

 " You also should ensure that your TLS environment is sane through testing
   with openssl's s_client and s_server codes. "



Cheers
Geert Stappers

Attachment: signature.asc
Description: Digital signature


Reply to: