Enabling TLS was not as straightforward as I'd hoped.
If I use ldaps://...:636
ptload does not appear to even attempt to negotiate TLS connection ne simply reports that a simple bind failed.
If I use ldap://...:389 and enable ldap_start_tls: 1
ptload sends LDAP_START_TLS_OID
The server responds with LDAP_START_TLS_OID
The client then sends something in SSL and the process times out.
If I use ldapsearch with the ldaps://...:636 and the same bind credentials, it issues a client Hello the server responds with server hello and they negotiate a TLS1.2 connection and data is passed.
If I use ldapsearch with the ldap://...:389, -ZZ and the same bind credentials
ldapsearch sends LDAP_START_TLS_OID
The server responds with LDAP_START_TLS_OID
ldapsearch then sends client hello, servers responds and offer certificates and TLS1.2 connection is negotiated and data is passed.
Is there something messed up in ptload so it isn't sending a client hello to start a TLS session? I don't see anything in the imap.conf options that would affect this, I have set the path to the CA cert for the LDAP server so it will be happy once it gets the certificate, but it isn't even asking for the certificate.
Did I miss something at compile time that is needed to get ptload built with SSL support? Cyrus-imapd has it OK, it offers starttls to the client (e.g. imtest) and negotiates its fine, but ptloader doesn't seem to know about starting a TLS session.
My imap server and my LDAP server are both on the same LAN so TLS between them is not critical right now, but I think microsoft will look to enforce encrypted LDAP lookups on AD DCs in the future so it would be best to get it working now if possible.
Regards
Jim
