On 06/11/17 21:07, Emmanuel Lécharny wrote:

Le 06/11/2017 à 19:19, Serge Pouliquen a écrit :
Hi,

I reply on my own message.

I made additionnal tests.
I generated a new certificate to server called 'testldap' and place an
exception in thunderbird in order to have it valid in thuderbird.

steps to reproduce : start computer, start thunderbird, open compose
window, type some letters in recipient field in order to auto-complete
with ldap search

test1 : testldap is set to 127.0.0.1 (in /etc/hosts)
  -> result is no auto complete on the first request (after stop start
thunderbird, ldap auto-complete is fine)

test2 : testldap is set (in /etc/hosts) to isp router and isp router
is set to redirect port to the computer
  -> result is auto complete is functional on the first request (and
futures)
I identified that auto complete is really longer to display proposed
addresses

My apache ds instance is request with localhost and the filesystem for
apache ds is a ramdisk. So it's really fast, almost instantly.

I don't really believe that a bug report like that will be processed
by thunderbird developpers.
Do you have any idea to improve my bug report ?

Is there an option to slowing or delaying apache ds ?
I really don't think that the server speed has anything to do with your
problem : it's very likely that the LDAP client used in TB is blocking
(ie it will wait for the answer once the request has been sent).

There must be something to do with the certificate and the name. using
127.0.0.1 might not match the certificate host you have set.

I hope the client will wait for the answer.
I attached to that message the certificate used with test1 and test2 reported above. certificate host name is matching the one in url but there is no certificate authority, so I added an exception in thunderbird.
between test1 and test2, the only change made is /etc/hosts.
It may be the way localhost is managed.
It cannot be the certificate name the root cause, because I can have auto complete by doing a request with address book window or restarting thunderbird. Otherwise, It should always fail, and it's not what is happening.

> To verify, allow your apache ds to listen on a clear-text (non secure) port like 389.  Set Thunderbird to use that same clear-text port.  If it is a basic connection issue this would help prove that.  If using ldap port 389 (or some other non-secure configuration) works, that might point to the ssl handshake and or cert issue.
Completely functional on unsecure / clear port.
> that might point to the ssl handshake and or cert issue.
But I believe that if ssl handshake or cert issue, all request should fail (because rejected or drop for security reason). Am I wrong ? The bypass / exception (to trust the certificate) in thunderbird should be OK or KO but only one of the two.

Regards,
Serge

Attachment: testldap.crt
Description: application/pkix-cert

Reply via email to