Re: Delta-Sync w/ TLS troubles

[Buchan Milne <bgmilne@staff.telkomsa.net>]

On Tuesday 30 June 2009 21:12:08 Peter Clark wrote:
> Hello,
>
> I have a FreeBSD 7.2 Release box with openldap-2.4.16 installed on it. I
> have followed the Admin guide to setting up Delta-Sync replication and
> it works as long as I do not use either the "ldaps" or "starttls=yes" on
> the slave. ie:
>
> syncrepl  rid=0
>          provider=ldap://joe.pdq.edu
>          starttls=yes
>          bindmethod=simple
>          binddn="cn=ldaproot,dc=pdq,dc=edu"
>          credentials="XXXXXXXXX"
>          searchbase="dc=pdq,dc=edu"
>          logbase="cn=accesslog"
>          logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
>          schemachecking=on
>          type=refreshAndPersist
>          retry="60 +"
>          syncdata=accesslog
>
> or
>
> syncrepl  rid=0
>          provider=ldaps://joe.pdq.edu
>          bindmethod=simple
>          binddn="cn=ldaproot,dc=mtmary,dc=edu"
>          credentials="XXXXXXXX"
>          searchbase="dc=pdq,dc=edu"
>          logbase="cn=accesslog"
>          logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
>          schemachecking=on
>          type=refreshAndPersist
>          retry="60 +"
>          syncdata=accesslog
>

I note you don't have the tls_cacert  or tls_cacertdir option specified, and 
neither the tls_reqcert, or tls_crlcheck options.

>
> I have set my loglevel to -1 on both boxes and the only thing that shows
> up in the logs referring to tls is:
>
> (Master server)
> slapd[9572]: conn=1 op=0 EXT oid=1.3.6.1.4.1.1466.20037
> slapd[9572]: do_extended: oid=1.3.6.1.4.1.1466.20037
> slapd[9572]: conn=1 op=0 STARTTLS
> slapd[9572]: send_ldap_extended: err=0 oid= len=0
> slapd[9572]: send_ldap_response: msgid=1 tag=120 err=0
> slapd[9572]: conn=1 op=0 RESULT oid= err=0 text=
> slapd[9572]: daemon: activity on 1 descriptor
> slapd[9572]: connection_read(16): checking for input on id=1
> slapd[9572]: connection_read(16): TLS accept failure error=-1 id=1, closing
> slapd[9572]: connection_closing: readying conn=1 sd=16 for close
> slapd[9572]: connection_close: conn=1 sd=16
> slapd[9572]: daemon: removing 16
> slapd[9572]: conn=1 fd=16 closed (TLS negotiation failure)
>
>
> (Slave Server)
> slapd[10846]: =>do_syncrepl rid=000
> slapd[10846]: daemon: activity on 1 descriptor
> slapd[10846]: daemon: waked
> slapd[10846]: daemon: select: listen=6 active_threads=0 tvp=zero
> lapd[10846]: daemon: select: listen=7 active_threads=0 tvp=zero
> slapd[10846]: daemon: select: listen=8 active_threads=0 tvp=zero
> slapd[10846]: daemon: select: listen=9 active_threads=0 tvp=zero
> slapd[10846]: slap_client_connect: URI=ldap://joe.pdq.edu Warning,
> ldap_start_tls failed (-11)
> slapd[10846]: slap_client_connect: URI=ldap://joe.pdq.edu
> DN="cn=ldaproot,dc=pdq,dc=edu" ldap_sasl_bind_s failed (-1)
>
>
>
> Is there some way to see what exactly is failing between the units? I
> have tried the credentials line with quotes around the password and
> without. I have made sure the provider= the fqdn of the master. Any help
> would be appreciated.

Can you use start_tls with an OpenLDAP client ? E.g. does:

$ ldapwhoami -x -ZZ -H ldap://joe.pdq.edu

work ?

If not, then you need to consider the usual certificate validation rules:
-Server must have a server cert
-Cert (chain) must be signed by a trusted CA certificate available locally on 
the client
-The subject CN on the cert must match the hostname you are using to connect 
as

If your syncrepl configuration for TLS must differ from that for the OpenLDAP 
command-line clients, you must specify the tls_ options in the syncrepl 
statement, otherwise I believe setting them in the OpenLDAP ldap.conf is 
sufficient (and then you can test with the OpenLDAP commandline clients).

If you still don't come right, then you should make logging more verbose on 
the client side ...

Regards,
Buchan