You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by Serge Pouliquen <sp...@free.fr> on 2017/11/03 20:00:24 UTC
apache DS + thunderbird : issue with TLS, while clear is functional
Hi,
I'm using apache DS embedded in a java app in order to store my address
book.
My thunderbird is configured to complete addresses only with that ldap
server (not with local adress book).
When I use it without TLS, it is completely functional.
When I use TLS, I cannot complete address from compose window until I
made a request to ldap server from address book window.
1/ Once I made one request from address book window, I got address
completion from compose window
2/ I can stop and start thunderbird, I still have completion.
3/ I don't have any firewall
4/ url is based on localhost and certificate is acceptable (tested fine
with address book window)
5/ I can reproduce on linux (debian stretch) and on windows 10 (client
and software on the same machine)
6/ on linux, with wireshark, when compose window is not completing
addresses, there is no traffic at all (on loopback)
Is someone aware of something similar ?
Have you any idea of workaround ? (go to address book window in order to
make one request is not really acceptable)
I don't have any good reason to think apache ds is culprit (because
looks good from adress book window).
I hope ldap is quite functional feature in thunderbird.
For particular reason, I will appreciate to switch from clear to TLS.
Thanks for apache ds software
Regards
Serge
Re: apache DS + thunderbird : issue with TLS, while clear is
functional
Posted by Serge Pouliquen <sp...@free.fr>.
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
Re: apache DS + thunderbird : issue with TLS, while clear is
functional
Posted by "Lohr, Donald" <lo...@jmu.edu>.
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.
D
On 11/06/2017 03:07 PM, 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.
>
--
D o n a l d L o h r
I n f o r m a t i o n S y s t e m s
J a m e s M a d i s o n U n i v e r s i t y
5 4 0 . 5 6 8 . 3 7 3 0
Re: apache DS + thunderbird : issue with TLS, while clear is
functional
Posted by Emmanuel Lécharny <el...@gmail.com>.
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.
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: apache DS + thunderbird : issue with TLS, while clear is
functional
Posted by Serge Pouliquen <sp...@free.fr>.
Hi,
Interesting question.
I'm planning to use the same piece of software on multiple devices : at
home on my main station, at work.
An other idea is to share that piece of software with family (in order
to have a unique address book) : some localhost, some over the wire...
and TLS will be mandatory...
I would prefer to avoid to many different settings on each device.
At work, I don't really trust admin, but I can't really keep them out
(they are root).
TLS is not mandatory, but I work a future idea that I would like to
implement.
I would like to use localhost for me (in order to test modification and
fast access) and set other other devices over the wire.
Maybe I should drop TLS for localhost connection.
I was surprised about my issue with localhost (sometimes it works,
sometimes not).
I will try to investigate a bit more on my certificate.
I know that if I allow clear transmission (for localhost), one day I
will configure access to that server for test purpose. Obviously, I will
forgot to change that after the test.
Thanks a lot for previous messages, it helps me
Regards
Serge
On 07/11/17 09:55, Lothar Haeger wrote:
> Serge Pouliquen wrote:
>
>> Using thunderbird to connect localhost service
> Why use TLS in the first place if nothing ever goes over the wire? Is there
> anything running on your workstation you do not trust so you need to
> specifically protect your address book from it (rather than getting rid of it
> completely)?
>
>
Re: apache DS + thunderbird : issue with TLS, while clear is functional
Posted by Lothar Haeger <lo...@brummelhook.com>.
Emmanuel Lécharny wrote:
> I would rather say : "whay not using TLS at the first place ?". There is
> no reason to expect the LDAP server to run locally, and there is no
> reason to expect your network not being hacked those days. Setting TLS
> is just a matter of common sense.
If there is a chance for the comms to get overheard by someone malicious, I'd
agree.
But there's a cost to TLS (time spent making it work, right here nad now, also
CPU, memory, battery life etc) and any cert WILL expire and break comms at some
point unless you remember (in a few years probably) to renew them just in time.
All worth it if protection is needed, all wasted effort if both server and
client are bound to loopback exclusively.
But Serge already pointed out it all makes sense here, so nothing left to argue
about. :-)
Re: apache DS + thunderbird : issue with TLS, while clear is
functional
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 07/11/2017 à 09:55, Lothar Haeger a écrit :
> Serge Pouliquen wrote:
>
>> Using thunderbird to connect localhost service
> Why use TLS in the first place if nothing ever goes over the wire? Is there
> anything running on your workstation you do not trust so you need to
> specifically protect your address book from it (rather than getting rid of it
> completely)?
I would rather say : "whay not using TLS at the first place ?". There is
no reason to expect the LDAP server to run locally, and there is no
reason to expect your network not being hacked those days. Setting TLS
is just a matter of common sense.
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: apache DS + thunderbird : issue with TLS, while clear is functional
Posted by Lothar Haeger <lo...@brummelhook.com>.
Serge Pouliquen wrote:
> Using thunderbird to connect localhost service
Why use TLS in the first place if nothing ever goes over the wire? Is there
anything running on your workstation you do not trust so you need to
specifically protect your address book from it (rather than getting rid of it
completely)?
Re: apache DS + thunderbird : issue with TLS, while clear is
functional
Posted by Serge Pouliquen <sp...@free.fr>.
Hi,
> are you trying to get autocomplete to work with ldap on thunderbird?
yes
> directory server in thunderbird?
yes
> i am using a letsencrypt certificate
you probably have a dedicated or real server.
I'm using my workstation to host apache ds.
Currently, I'm suspecting apache ds to answering too fast and
thunderbird may have an issue with too fast connection.
Using thunderbird to connect localhost service is not the regular case.
In my last message, I was reporting that by emulating network (and not
localhost), it was functionnal with the same software settings
(thunderbird and apache ds).
Regards,
Serge
On 06/11/17 19:25, Matthew Broadhead wrote:
> hi, i haven't read the entire thread but are you trying to get
> autocomplete to work with ldap on thunderbird? i am using a
> letsencrypt certificate on apache ds without problem. did you do
> preferences -> composition -> addressing -> directory server in
> thunderbird?
>
> On 06/11/2017 19:19, Serge Pouliquen wrote:
>> 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 ?
>> Ideally only the first request from a client.
>> Do you think it is possible to do something like that with interceptor ?
>> (http://directory.apache.org/apacheds/advanced-ug/6-implementing-interceptor.html)
>>
>>
>> I still find that strange.
>> Regards,
>> Serge
>>
>>
>> On 06/11/17 00:20, Serge Pouliquen wrote:
>>> Hi,
>>>
>>> When trying with thunderbird log, I noticed that the first
>>> auto-complete request was producing logs on apache ds (with
>>> -Djavax.net.debug=all) and not the later.
>>> I suspected my certificate (generated by me with my own CA). I tried
>>> a certificate generated with the tuto from apache ds website. It
>>> looks like auto-complete is more frequent.
>>> http://directory.apache.org/apacheds/basic-ug/3.3-enabling-ssl.html#in-case-you-want-to-use-an-external-keystore
>>>
>>>
>>> With the certificate generated according to apache ds website, I can
>>> stop/start thunderbirdand apacheds in almost any order, it will
>>> still autocomplete once auto-complete has succeeded. I only found
>>> that to have the issue back is to restart computer or restart apache
>>> ds while thundebird is still running (thunderbird restart will
>>> restore auto complete back). It looks like a cache is cleaned on
>>> restart (amazing question to find which one...) or ldap connection
>>> are not inited again on failed status (maybe a feature).
>>>
>>>
>>> I still don't know what is the root cause issue but it looks related
>>> or interfered by data in certificate.
>>> The first request may ask some resource, not provided in time. So
>>> current request is considered timeout, connection is considered
>>> failed. But resource are loaded.
>>> Future request may fail if based on the failed connection (that may
>>> be the reason why I wasn't seeing any traffic on the network) or
>>> succeded if a new connection is inited (with resource in a cache). I
>>> don't know how I can check above.
>>> In thunderbird, adress book window and auto-complete may not be
>>> processing request the same way.
>>>
>>> Below, there is some logs (I didn't noticed any issue, but I may be
>>> wrong)
>>>
>>> Is someone using a certificate made by a similar command (apache ds
>>> tuto) with thunderbird without issue ?
>>>
>>> Is that possible that localhost is so fast, that it produced error
>>> that are not visible in real network world ?
>>>
>>> Thanks for the previous suggestions, it helps me to move a bit forward,
>>>
>>> Serge
>>>
>>>
>>>
>>> On 05/11/17 00:02, Emmanuel Lécharny wrote:
>>>> Le 04/11/2017 à 19:57, Jason a écrit :
>>>>> If you are using the auto generated self signed certificates try a
>>>>> version
>>>>> 1.7 jvm or generate your own certs. I think the DS selfsigned
>>>>> certs are not
>>>>> created correctly in a 1.8 Jvm due to changes in supported crypto
>>>>> algorithms.
>>>> You can change the self-signed certificate. It's provided for
>>>> convenience only.
>>>>
>>>> We may generate a new one for Java 8 in a later release.
>>>>
>>>
>>
>
Re: apache DS + thunderbird : issue with TLS, while clear is
functional
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
hi, i haven't read the entire thread but are you trying to get
autocomplete to work with ldap on thunderbird? i am using a letsencrypt
certificate on apache ds without problem. did you do preferences ->
composition -> addressing -> directory server in thunderbird?
On 06/11/2017 19:19, Serge Pouliquen wrote:
> 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 ?
> Ideally only the first request from a client.
> Do you think it is possible to do something like that with interceptor ?
> (http://directory.apache.org/apacheds/advanced-ug/6-implementing-interceptor.html)
>
>
> I still find that strange.
> Regards,
> Serge
>
>
> On 06/11/17 00:20, Serge Pouliquen wrote:
>> Hi,
>>
>> When trying with thunderbird log, I noticed that the first
>> auto-complete request was producing logs on apache ds (with
>> -Djavax.net.debug=all) and not the later.
>> I suspected my certificate (generated by me with my own CA). I tried
>> a certificate generated with the tuto from apache ds website. It
>> looks like auto-complete is more frequent.
>> http://directory.apache.org/apacheds/basic-ug/3.3-enabling-ssl.html#in-case-you-want-to-use-an-external-keystore
>>
>>
>> With the certificate generated according to apache ds website, I can
>> stop/start thunderbirdand apacheds in almost any order, it will still
>> autocomplete once auto-complete has succeeded. I only found that to
>> have the issue back is to restart computer or restart apache ds while
>> thundebird is still running (thunderbird restart will restore auto
>> complete back). It looks like a cache is cleaned on restart (amazing
>> question to find which one...) or ldap connection are not inited
>> again on failed status (maybe a feature).
>>
>>
>> I still don't know what is the root cause issue but it looks related
>> or interfered by data in certificate.
>> The first request may ask some resource, not provided in time. So
>> current request is considered timeout, connection is considered
>> failed. But resource are loaded.
>> Future request may fail if based on the failed connection (that may
>> be the reason why I wasn't seeing any traffic on the network) or
>> succeded if a new connection is inited (with resource in a cache). I
>> don't know how I can check above.
>> In thunderbird, adress book window and auto-complete may not be
>> processing request the same way.
>>
>> Below, there is some logs (I didn't noticed any issue, but I may be
>> wrong)
>>
>> Is someone using a certificate made by a similar command (apache ds
>> tuto) with thunderbird without issue ?
>>
>> Is that possible that localhost is so fast, that it produced error
>> that are not visible in real network world ?
>>
>> Thanks for the previous suggestions, it helps me to move a bit forward,
>>
>> Serge
>>
>>
>>
>> On 05/11/17 00:02, Emmanuel Lécharny wrote:
>>> Le 04/11/2017 à 19:57, Jason a écrit :
>>>> If you are using the auto generated self signed certificates try a
>>>> version
>>>> 1.7 jvm or generate your own certs. I think the DS selfsigned certs
>>>> are not
>>>> created correctly in a 1.8 Jvm due to changes in supported crypto
>>>> algorithms.
>>> You can change the self-signed certificate. It's provided for
>>> convenience only.
>>>
>>> We may generate a new one for Java 8 in a later release.
>>>
>>
>
Re: apache DS + thunderbird : issue with TLS, while clear is
functional
Posted by Serge Pouliquen <sp...@free.fr>.
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 ?
Ideally only the first request from a client.
Do you think it is possible to do something like that with interceptor ?
(http://directory.apache.org/apacheds/advanced-ug/6-implementing-interceptor.html)
I still find that strange.
Regards,
Serge
On 06/11/17 00:20, Serge Pouliquen wrote:
> Hi,
>
> When trying with thunderbird log, I noticed that the first
> auto-complete request was producing logs on apache ds (with
> -Djavax.net.debug=all) and not the later.
> I suspected my certificate (generated by me with my own CA). I tried a
> certificate generated with the tuto from apache ds website. It looks
> like auto-complete is more frequent.
> http://directory.apache.org/apacheds/basic-ug/3.3-enabling-ssl.html#in-case-you-want-to-use-an-external-keystore
>
>
> With the certificate generated according to apache ds website, I can
> stop/start thunderbirdand apacheds in almost any order, it will still
> autocomplete once auto-complete has succeeded. I only found that to
> have the issue back is to restart computer or restart apache ds while
> thundebird is still running (thunderbird restart will restore auto
> complete back). It looks like a cache is cleaned on restart (amazing
> question to find which one...) or ldap connection are not inited again
> on failed status (maybe a feature).
>
>
> I still don't know what is the root cause issue but it looks related
> or interfered by data in certificate.
> The first request may ask some resource, not provided in time. So
> current request is considered timeout, connection is considered
> failed. But resource are loaded.
> Future request may fail if based on the failed connection (that may be
> the reason why I wasn't seeing any traffic on the network) or succeded
> if a new connection is inited (with resource in a cache). I don't know
> how I can check above.
> In thunderbird, adress book window and auto-complete may not be
> processing request the same way.
>
> Below, there is some logs (I didn't noticed any issue, but I may be
> wrong)
>
> Is someone using a certificate made by a similar command (apache ds
> tuto) with thunderbird without issue ?
>
> Is that possible that localhost is so fast, that it produced error
> that are not visible in real network world ?
>
> Thanks for the previous suggestions, it helps me to move a bit forward,
>
> Serge
>
>
>
> On 05/11/17 00:02, Emmanuel Lécharny wrote:
>> Le 04/11/2017 à 19:57, Jason a écrit :
>>> If you are using the auto generated self signed certificates try a
>>> version
>>> 1.7 jvm or generate your own certs. I think the DS selfsigned certs
>>> are not
>>> created correctly in a 1.8 Jvm due to changes in supported crypto
>>> algorithms.
>> You can change the self-signed certificate. It's provided for
>> convenience only.
>>
>> We may generate a new one for Java 8 in a later release.
>>
>
Re: apache DS + thunderbird : issue with TLS, while clear is
functional
Posted by Serge Pouliquen <sp...@free.fr>.
Hi,
When trying with thunderbird log, I noticed that the first auto-complete
request was producing logs on apache ds (with -Djavax.net.debug=all) and
not the later.
I suspected my certificate (generated by me with my own CA). I tried a
certificate generated with the tuto from apache ds website. It looks
like auto-complete is more frequent.
http://directory.apache.org/apacheds/basic-ug/3.3-enabling-ssl.html#in-case-you-want-to-use-an-external-keystore
With the certificate generated according to apache ds website, I can
stop/start thunderbirdand apacheds in almost any order, it will still
autocomplete once auto-complete has succeeded. I only found that to have
the issue back is to restart computer or restart apache ds while
thundebird is still running (thunderbird restart will restore auto
complete back). It looks like a cache is cleaned on restart (amazing
question to find which one...) or ldap connection are not inited again
on failed status (maybe a feature).
I still don't know what is the root cause issue but it looks related or
interfered by data in certificate.
The first request may ask some resource, not provided in time. So
current request is considered timeout, connection is considered failed.
But resource are loaded.
Future request may fail if based on the failed connection (that may be
the reason why I wasn't seeing any traffic on the network) or succeded
if a new connection is inited (with resource in a cache). I don't know
how I can check above.
In thunderbird, adress book window and auto-complete may not be
processing request the same way.
Below, there is some logs (I didn't noticed any issue, but I may be wrong)
Is someone using a certificate made by a similar command (apache ds
tuto) with thunderbird without issue ?
Is that possible that localhost is so fast, that it produced error that
are not visible in real network world ?
Thanks for the previous suggestions, it helps me to move a bit forward,
Serge
Thunderbird is producing :
// first request without auto complete
2017-11-05 21:05:47.827192 UTC - 103454528[7f7804e73140]:
nsLDAPOperation::SimpleBind(): called; bindName = 'cn=view,ou=system';
2017-11-05 21:05:47.915195 UTC - 103454528[7f7804e73140]: pending
operation added; total pending operations now = 1
// second request with autocomplete
2017-11-05 21:09:31.392806 UTC - 103454528[7f7804e73140]:
nsLDAPOperation::SimpleBind(): called; bindName = 'cn=view,ou=system';
2017-11-05 21:09:31.396382 UTC - 103454528[7f7804e73140]: pending
operation added; total pending operations now = 1
2017-11-05 21:09:31.399426 UTC - -991955200[7f77c329ed60]: pending
operation removed; total pending operations now = 0
2017-11-05 21:09:31.399478 UTC - 103454528[7f7804e73140]:
nsLDAPOperation::SearchExt(): called with aBaseDn = 'dc=contacts';
aFilter = '(|(cn=serg**)(mail=serg**)(sn=serg**))'; aAttributes =
cn,commonname,mail,objectClass; aSizeLimit = 100
2017-11-05 21:09:31.399526 UTC - 103454528[7f7804e73140]: pending
operation added; total pending operations now = 1
2017-11-05 21:09:31.409165 UTC - 103454528[7f7804e73140]:
nsLDAPMessage::GetDn(): dn = 'cn=Serge Pouliquen Free,dc=contacts'
... hidden results...
2017-11-05 21:09:31.410258 UTC - -991955200[7f77c329ed60]: pending
operation removed; total pending operations now = 0
apache ds is producing these logs on the first request:
Using SSLEngineImpl.
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Ignoring unsupported cipher suite:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
for TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite:
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
for TLSv1
Ignoring unsupported cipher suite:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for
TLSv1.1
Ignoring unsupported cipher suite:
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
for TLSv1.1
[Raw read]: length = 5
0000: 16 03 01 00 A7 .....
[Raw read]: length = 167
0000: 01 00 00 A3 03 03 70 30 AF 6C 3B C6 C5 88 4E 17 ......p0.l;...N.
0010: F8 94 6E 6C D4 67 B6 81 A0 B4 D7 CF 06 34 C3 0A ..nl.g.......4..
0020: B0 B2 BE 32 14 2A 00 00 1E C0 2B C0 2F CC A9 CC ...2.*....+./...
0030: A8 C0 2C C0 30 C0 0A C0 09 C0 13 C0 14 00 33 00 ..,.0.........3.
0040: 39 00 2F 00 35 00 0A 01 00 00 5C 00 00 00 0E 00 9./.5.....\.....
0050: 0C 00 00 09 6C 6F 63 61 6C 68 6F 73 74 00 17 00 ....localhost...
0060: 00 FF 01 00 01 00 00 0A 00 0A 00 08 00 1D 00 17 ................
0070: 00 18 00 19 00 0B 00 02 01 00 00 23 00 00 00 05 ...........#....
0080: 00 05 01 00 00 00 00 FF 03 00 00 00 0D 00 18 00 ................
0090: 16 04 03 05 03 06 03 08 04 08 05 08 06 04 01 05 ................
00A0: 01 06 01 02 03 02 01 .......
NioProcessor-2, READ: TLSv1 Handshake, length = 167
*** ClientHello, TLSv1.2
RandomCookie: GMT: 1882173292 bytes = { 59, 198, 197, 136, 78, 23, 248,
148, 110, 108, 212, 103, 182, 129, 160, 180, 215, 207, 6, 52, 195, 10,
176, 178, 190, 50, 20, 42 }
Session ID: {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, Unknown 0xcc:0xa9, Unknown
0xcc:0xa8, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
SSL_RSA_WITH_3DES_EDE_CBC_SHA]
Compression Methods: { 0 }
Extension server_name, server_name: [type=host_name (0), value=localhost]
Unsupported extension type_23, data:
Extension renegotiation_info, renegotiated_connection: <empty>
Extension elliptic_curves, curve names: {unknown curve 29, secp256r1,
secp384r1, secp521r1}
Extension ec_point_formats, formats: [uncompressed]
Unsupported extension type_35, data:
Unsupported extension status_request, data: 01:00:00:00:00
Unsupported extension type_65283, data:
Extension signature_algorithms, signature_algorithms: SHA256withECDSA,
SHA384withECDSA, SHA512withECDSA, Unknown (hash:0x8, signature:0x4),
Unknown (hash:0x8, signature:0x5), Unknown (hash:0x8, signature:0x6),
SHA256withRSA, SHA384withRSA, SHA512withRSA, SHA1withECDSA, SHA1withRSA
***
[read] MD5 and SHA1 hashes: len = 167
0000: 01 00 00 A3 03 03 70 30 AF 6C 3B C6 C5 88 4E 17 ......p0.l;...N.
0010: F8 94 6E 6C D4 67 B6 81 A0 B4 D7 CF 06 34 C3 0A ..nl.g.......4..
0020: B0 B2 BE 32 14 2A 00 00 1E C0 2B C0 2F CC A9 CC ...2.*....+./...
0030: A8 C0 2C C0 30 C0 0A C0 09 C0 13 C0 14 00 33 00 ..,.0.........3.
0040: 39 00 2F 00 35 00 0A 01 00 00 5C 00 00 00 0E 00 9./.5.....\.....
0050: 0C 00 00 09 6C 6F 63 61 6C 68 6F 73 74 00 17 00 ....localhost...
0060: 00 FF 01 00 01 00 00 0A 00 0A 00 08 00 1D 00 17 ................
0070: 00 18 00 19 00 0B 00 02 01 00 00 23 00 00 00 05 ...........#....
0080: 00 05 01 00 00 00 00 FF 03 00 00 00 0D 00 18 00 ................
0090: 16 04 03 05 03 06 03 08 04 08 05 08 06 04 01 05 ................
00A0: 01 06 01 02 03 02 01 .......
%% Initialized: [Session-13, SSL_NULL_WITH_NULL_NULL]
Standard ciphersuite chosen: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
%% Negotiating: [Session-13, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
*** ServerHello, TLSv1.2
RandomCookie: GMT: 1493138731 bytes = { 129, 224, 223, 50, 34, 152, 24,
215, 178, 156, 74, 195, 176, 148, 192, 74, 132, 178, 34, 15, 251, 117,
161, 54, 188, 175, 151, 146 }
Session ID: {89, 255, 125, 43, 113, 239, 193, 48, 49, 23, 35, 234, 184,
246, 101, 152, 174, 35, 154, 74, 1, 36, 201, 95, 82, 133, 52, 178, 158,
124, 222, 78}
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***
Cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=localhost, OU=ApacheDS, O=ASF, C=US
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
Key: Sun RSA public key, 2048 bits
modulus:
18158371819303472058666946520215784093296003061009163340702729000174536295532616311419171356792272539487662198014482295916866820812816534302578341101442760047183883031177804276729462690273686210634874522484863915257182700941522314866732046062854544733055534006031946980796225052285469801746810837856249643712504393445213998267715551521213479128633124512538094911849850625272565153941846874621033171853682668617514147357493814302325639254080275009859485245786918566835949223531924071791170472877537289439532990607040826617336011924600375017317264865517314312678361250574155751416366283425551388747338300352505880834881
public exponent: 65537
Validity: [From: Sun Nov 05 00:48:03 CET 2017,
To: Tue Nov 05 00:48:03 CET 2019]
Issuer: CN=localhost, OU=ApacheDS, O=ASF, C=US
SerialNumber: [ 43a2322d]
Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 6E 60 ED 72 98 79 CF 52 32 15 63 BB B6 F6 95 4A n`.r.y.R2.c....J
0010: 5F 17 A2 D7 _...
]
]
]
Algorithm: [SHA256withRSA]
Signature:
0000: 40 DA 72 E6 EB DF 04 8C 0C 33 E5 98 91 9F 23 4A @.r......3....#J
0010: B0 11 EB 73 52 BB 58 3A 16 0C A2 AE A6 6C 3D DD ...sR.X:.....l=.
0020: D3 07 65 52 7E 34 DE 3C F0 FB D1 7A 5C 12 15 10 ..eR.4.<...z\...
0030: EE 86 ED 3F 19 15 1E 98 3B 3E 1B 22 AF 2F 8C 8F ...?....;>."./..
0040: 4C 86 F9 A0 E3 FA A2 09 0B 43 9C 63 7B 86 AD BF L........C.c....
0050: EA 3E 8E 78 8A 2B 4E 37 1C E8 2F C7 BC A8 24 50 .>.x.+N7../...$P
0060: 2F AF D5 DA 1C 89 DE F9 2D 83 6F A4 19 F7 D0 C7 /.......-.o.....
0070: 85 CD 81 0F 6E 35 A6 74 6C 60 2F 6B 9D B5 F3 EF ....n5.tl`/k....
0080: 5E CA 53 96 E9 E9 A9 CC 0B 7D DC E3 DE B3 E8 45 ^.S............E
0090: 11 AB BD 53 6A A6 D6 6A 1B 2D 55 17 55 41 EE 11 ...Sj..j.-U.UA..
00A0: A7 FC 11 68 F4 21 42 FC 47 62 5A 48 DD 76 42 CB ...h.!B.GbZH.vB.
00B0: 17 9B 2F EF 4B 43 41 B9 39 DD A1 36 FB 90 59 62 ../.KCA.9..6..Yb
00C0: FA FA A5 78 97 57 8A 8C 7F 5D 4C C8 09 B8 6D 60 ...x.W...]L...m`
00D0: D7 AC A3 72 05 11 60 0F 12 42 7A 48 57 05 CA 7E ...r..`..BzHW...
00E0: 90 2B 1A 3E BE 65 FC 7B 84 48 D5 4A BE 44 1C D5 .+.>.e...H.J.D..
00F0: 10 08 BC 3A 52 47 AF 9F 55 01 95 77 60 EF D9 D6 ...:RG..U..w`...
]
***
*** ECDH ServerKeyExchange
Signature Algorithm SHA256withRSA
Server key: Sun EC public key, 256 bits
public x coord:
62445053184465021774534846422992387465080273352792479454330392825590771955442
public y coord:
72709279762004503871828128002940834530403665276468780366296033684786152516376
parameters: secp256r1 [NIST P-256, X9.62 prime256v1]
(1.2.840.10045.3.1.7)
*** ServerHelloDone
[write] MD5 and SHA1 hashes: len = 1235
0000: 02 00 00 4D 03 03 59 FF 7D 2B 81 E0 DF 32 22 98 ...M..Y..+...2".
0010: 18 D7 B2 9C 4A C3 B0 94 C0 4A 84 B2 22 0F FB 75 ....J....J.."..u
0020: A1 36 BC AF 97 92 20 59 FF 7D 2B 71 EF C1 30 31 .6.... Y..+q..01
0030: 17 23 EA B8 F6 65 98 AE 23 9A 4A 01 24 C9 5F 52 .#...e..#.J.$._R
0040: 85 34 B2 9E 7C DE 4E C0 2F 00 00 05 FF 01 00 01 .4....N./.......
0050: 00 0B 00 03 2D 00 03 2A 00 03 27 30 82 03 23 30 ....-..*..'0..#0
0060: 82 02 0B A0 03 02 01 02 02 04 43 A2 32 2D 30 0D ..........C.2-0.
0070: 06 09 2A 86 48 86 F7 0D 01 01 0B 05 00 30 42 31 ..*.H........0B1
0080: 0B 30 09 06 03 55 04 06 13 02 55 53 31 0C 30 0A .0...U....US1.0.
0090: 06 03 55 04 0A 13 03 41 53 46 31 11 30 0F 06 03 ..U....ASF1.0...
00A0: 55 04 0B 13 08 41 70 61 63 68 65 44 53 31 12 30 U....ApacheDS1.0
00B0: 10 06 03 55 04 03 13 09 6C 6F 63 61 6C 68 6F 73 ...U....localhos
00C0: 74 30 1E 17 0D 31 37 31 31 30 34 32 33 34 38 30 t0...17110423480
00D0: 33 5A 17 0D 31 39 31 31 30 34 32 33 34 38 30 33 3Z..191104234803
00E0: 5A 30 42 31 0B 30 09 06 03 55 04 06 13 02 55 53 Z0B1.0...U....US
00F0: 31 0C 30 0A 06 03 55 04 0A 13 03 41 53 46 31 11 1.0...U....ASF1.
0100: 30 0F 06 03 55 04 0B 13 08 41 70 61 63 68 65 44 0...U....ApacheD
0110: 53 31 12 30 10 06 03 55 04 03 13 09 6C 6F 63 61 S1.0...U....loca
0120: 6C 68 6F 73 74 30 82 01 22 30 0D 06 09 2A 86 48 lhost0.."0...*.H
0130: 86 F7 0D 01 01 01 05 00 03 82 01 0F 00 30 82 01 .............0..
0140: 0A 02 82 01 01 00 8F D7 8E 1E B7 53 75 DB 75 70 ...........Su.up
0150: 33 34 2A 01 FE 25 A5 89 5A 81 4D CC 43 78 13 15 34*..%..Z.M.Cx..
0160: B2 99 1B 49 F7 81 54 6A 3C 07 9D A7 34 DE 4B B9 ...I..Tj<...4.K.
0170: 4D 98 9F 92 E0 EC 0A C3 06 37 C4 47 C7 81 4E 65 M........7.G..Ne
0180: 53 3D 33 E5 00 A4 74 0A 16 4A 9A 59 AB E5 09 7A S=3...t..J.Y...z
0190: A8 FE 5B 53 F1 DF E0 85 2F CE 4F B2 5A 74 EF A4 ..[S..../.O.Zt..
01A0: D7 41 E2 AA B4 49 4D A2 0C 2C 7D 71 AF 90 50 D5 .A...IM..,.q..P.
01B0: 52 FB 2C 4E D9 66 D9 10 F7 C1 83 FA 44 EE 76 01 R.,N.f......D.v.
01C0: 33 05 1B 65 62 B9 9B 0A 1A F6 5A 7D 90 A6 42 F2 3..eb.....Z...B.
01D0: E0 87 71 71 96 9F 1C E9 B7 27 EA 5C 07 BD F6 BD ..qq.....'.\....
01E0: F3 59 4C 3B A5 E3 10 C2 56 5B D0 A9 74 FC 73 BC .YL;....V[..t.s.
01F0: 8F 14 BA 3C 7D AF 1F 88 F2 EF CF 68 49 3C 74 3A ...<.......hI<t:
0200: 37 CC EA 49 AD CE 48 CA D2 13 37 09 89 AD DA 59 7..I..H...7....Y
0210: 33 F4 87 8F 5C 57 98 50 11 45 0C 64 B8 4A D7 62 3...\W.P.E.d.J.b
0220: 27 A7 CC 40 D1 A9 19 B1 6D 96 CA 19 90 4F 1E 34 '..@....m....O.4
0230: 4A FC 68 4F 14 BE 5E 2B CF A0 80 BC 50 D1 54 EE J.hO..^+....P.T.
0240: 48 A8 7F 54 F3 41 02 03 01 00 01 A3 21 30 1F 30 H..T.A......!0.0
0250: 1D 06 03 55 1D 0E 04 16 04 14 6E 60 ED 72 98 79 ...U......n`.r.y
0260: CF 52 32 15 63 BB B6 F6 95 4A 5F 17 A2 D7 30 0D .R2.c....J_...0.
0270: 06 09 2A 86 48 86 F7 0D 01 01 0B 05 00 03 82 01 ..*.H...........
0280: 01 00 40 DA 72 E6 EB DF 04 8C 0C 33 E5 98 91 9F ..@.r......3....
0290: 23 4A B0 11 EB 73 52 BB 58 3A 16 0C A2 AE A6 6C #J...sR.X:.....l
02A0: 3D DD D3 07 65 52 7E 34 DE 3C F0 FB D1 7A 5C 12 =...eR.4.<...z\.
02B0: 15 10 EE 86 ED 3F 19 15 1E 98 3B 3E 1B 22 AF 2F .....?....;>."./
02C0: 8C 8F 4C 86 F9 A0 E3 FA A2 09 0B 43 9C 63 7B 86 ..L........C.c..
02D0: AD BF EA 3E 8E 78 8A 2B 4E 37 1C E8 2F C7 BC A8 ...>.x.+N7../...
02E0: 24 50 2F AF D5 DA 1C 89 DE F9 2D 83 6F A4 19 F7 $P/.......-.o...
02F0: D0 C7 85 CD 81 0F 6E 35 A6 74 6C 60 2F 6B 9D B5 ......n5.tl`/k..
0300: F3 EF 5E CA 53 96 E9 E9 A9 CC 0B 7D DC E3 DE B3 ..^.S...........
0310: E8 45 11 AB BD 53 6A A6 D6 6A 1B 2D 55 17 55 41 .E...Sj..j.-U.UA
0320: EE 11 A7 FC 11 68 F4 21 42 FC 47 62 5A 48 DD 76 .....h.!B.GbZH.v
0330: 42 CB 17 9B 2F EF 4B 43 41 B9 39 DD A1 36 FB 90 B.../.KCA.9..6..
0340: 59 62 FA FA A5 78 97 57 8A 8C 7F 5D 4C C8 09 B8 Yb...x.W...]L...
0350: 6D 60 D7 AC A3 72 05 11 60 0F 12 42 7A 48 57 05 m`...r..`..BzHW.
0360: CA 7E 90 2B 1A 3E BE 65 FC 7B 84 48 D5 4A BE 44 ...+.>.e...H.J.D
0370: 1C D5 10 08 BC 3A 52 47 AF 9F 55 01 95 77 60 EF .....:RG..U..w`.
0380: D9 D6 0C 00 01 49 03 00 17 41 04 8A 0E A5 C9 84 .....I...A......
0390: A9 48 ED 7E 02 87 32 7A 88 5B 4D 3F AC CC 86 9A .H....2z.[M?....
03A0: 6E F4 86 17 5A 2D 99 BA 4D 36 F2 A0 BF FE 75 0D n...Z-..M6....u.
03B0: 84 02 80 F0 41 44 82 04 33 30 B2 00 AE 6F 53 95 ....AD..30...oS.
03C0: D9 C1 41 D8 90 F0 D5 F1 54 AB 18 04 01 01 00 1B ..A.....T.......
03D0: EB 30 F7 0A 78 47 32 1D 9E 60 8F 98 F6 D2 37 21 .0..xG2..`....7!
03E0: 0D C0 D8 51 1C 6B 2A 53 BE 1B A4 AF 57 B2 15 05 ...Q.k*S....W...
03F0: F8 DC 26 14 81 7A 64 CF D8 1D 64 01 32 2D A5 CA ..&..zd...d.2-..
0400: ED DA 2B A5 5C C8 FE 5E 00 9A E2 5F 64 7F 64 0B ..+.\..^..._d.d.
0410: 37 86 0F D8 3F F9 C1 46 C4 32 35 5F 98 25 3C 12 7...?..F.25_.%<.
0420: 3A 9B D9 4F 9C 9A 3F A7 75 AC 9A EC 43 8B 42 3D :..O..?.u...C.B=
0430: EB 12 8E 65 A9 1F 46 B1 13 73 8F A4 98 7B 0C D4 ...e..F..s......
0440: A9 41 3F F4 80 20 8D C5 30 42 C5 9F EC B8 37 AA .A?.. ..0B....7.
0450: E9 BC 2F 09 EC DB 50 AB 84 6B BB A2 E4 4D 45 C0 ../...P..k...ME.
0460: 0F 14 37 6C 80 18 04 20 AD 4E 05 35 1F 4F 35 A4 ..7l... .N.5.O5.
0470: 3C 80 B2 A9 66 17 EF 22 B1 48 3C DA 70 57 28 BC <...f..".H<.pW(.
0480: AA 81 E1 AB B3 BE 33 A0 3A E5 E8 10 62 A0 25 05 ......3.:...b.%.
0490: DC 7D 4F C0 1D 7B C5 1E 62 65 4E 15 5E 7B AA 47 ..O.....beN.^..G
04A0: 11 8C 92 39 2F E8 CB E2 8C 91 C7 A1 72 E6 35 23 ...9/.......r.5#
04B0: EC 4E 4C EB 92 8F B9 84 1F C7 31 83 62 D3 87 2D .NL.......1.b..-
04C0: 34 25 87 E4 D0 21 D3 DC FB 4D A9 6B 85 49 23 0E 4%...!...M.k.I#.
04D0: 00 00 00 ...
NioProcessor-2, WRITE: TLSv1.2 Handshake, length = 1235
[Raw write]: length = 1240
0000: 16 03 03 04 D3 02 00 00 4D 03 03 59 FF 7D 2B 81 ........M..Y..+.
0010: E0 DF 32 22 98 18 D7 B2 9C 4A C3 B0 94 C0 4A 84 ..2".....J....J.
0020: B2 22 0F FB 75 A1 36 BC AF 97 92 20 59 FF 7D 2B ."..u.6.... Y..+
0030: 71 EF C1 30 31 17 23 EA B8 F6 65 98 AE 23 9A 4A q..01.#...e..#.J
0040: 01 24 C9 5F 52 85 34 B2 9E 7C DE 4E C0 2F 00 00 .$._R.4....N./..
0050: 05 FF 01 00 01 00 0B 00 03 2D 00 03 2A 00 03 27 .........-..*..'
0060: 30 82 03 23 30 82 02 0B A0 03 02 01 02 02 04 43 0..#0..........C
0070: A2 32 2D 30 0D 06 09 2A 86 48 86 F7 0D 01 01 0B .2-0...*.H......
0080: 05 00 30 42 31 0B 30 09 06 03 55 04 06 13 02 55 ..0B1.0...U....U
0090: 53 31 0C 30 0A 06 03 55 04 0A 13 03 41 53 46 31 S1.0...U....ASF1
00A0: 11 30 0F 06 03 55 04 0B 13 08 41 70 61 63 68 65 .0...U....Apache
00B0: 44 53 31 12 30 10 06 03 55 04 03 13 09 6C 6F 63 DS1.0...U....loc
00C0: 61 6C 68 6F 73 74 30 1E 17 0D 31 37 31 31 30 34 alhost0...171104
00D0: 32 33 34 38 30 33 5A 17 0D 31 39 31 31 30 34 32 234803Z..1911042
00E0: 33 34 38 30 33 5A 30 42 31 0B 30 09 06 03 55 04 34803Z0B1.0...U.
00F0: 06 13 02 55 53 31 0C 30 0A 06 03 55 04 0A 13 03 ...US1.0...U....
0100: 41 53 46 31 11 30 0F 06 03 55 04 0B 13 08 41 70 ASF1.0...U....Ap
0110: 61 63 68 65 44 53 31 12 30 10 06 03 55 04 03 13 acheDS1.0...U...
0120: 09 6C 6F 63 61 6C 68 6F 73 74 30 82 01 22 30 0D .localhost0.."0.
0130: 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 82 01 ..*.H...........
0140: 0F 00 30 82 01 0A 02 82 01 01 00 8F D7 8E 1E B7 ..0.............
0150: 53 75 DB 75 70 33 34 2A 01 FE 25 A5 89 5A 81 4D Su.up34*..%..Z.M
0160: CC 43 78 13 15 B2 99 1B 49 F7 81 54 6A 3C 07 9D .Cx.....I..Tj<..
0170: A7 34 DE 4B B9 4D 98 9F 92 E0 EC 0A C3 06 37 C4 .4.K.M........7.
0180: 47 C7 81 4E 65 53 3D 33 E5 00 A4 74 0A 16 4A 9A G..NeS=3...t..J.
0190: 59 AB E5 09 7A A8 FE 5B 53 F1 DF E0 85 2F CE 4F Y...z..[S..../.O
01A0: B2 5A 74 EF A4 D7 41 E2 AA B4 49 4D A2 0C 2C 7D .Zt...A...IM..,.
01B0: 71 AF 90 50 D5 52 FB 2C 4E D9 66 D9 10 F7 C1 83 q..P.R.,N.f.....
01C0: FA 44 EE 76 01 33 05 1B 65 62 B9 9B 0A 1A F6 5A .D.v.3..eb.....Z
01D0: 7D 90 A6 42 F2 E0 87 71 71 96 9F 1C E9 B7 27 EA ...B...qq.....'.
01E0: 5C 07 BD F6 BD F3 59 4C 3B A5 E3 10 C2 56 5B D0 \.....YL;....V[.
01F0: A9 74 FC 73 BC 8F 14 BA 3C 7D AF 1F 88 F2 EF CF .t.s....<.......
0200: 68 49 3C 74 3A 37 CC EA 49 AD CE 48 CA D2 13 37 hI<t:7..I..H...7
0210: 09 89 AD DA 59 33 F4 87 8F 5C 57 98 50 11 45 0C ....Y3...\W.P.E.
0220: 64 B8 4A D7 62 27 A7 CC 40 D1 A9 19 B1 6D 96 CA d.J.b'..@....m..
0230: 19 90 4F 1E 34 4A FC 68 4F 14 BE 5E 2B CF A0 80 ..O.4J.hO..^+...
0240: BC 50 D1 54 EE 48 A8 7F 54 F3 41 02 03 01 00 01 .P.T.H..T.A.....
0250: A3 21 30 1F 30 1D 06 03 55 1D 0E 04 16 04 14 6E .!0.0...U......n
0260: 60 ED 72 98 79 CF 52 32 15 63 BB B6 F6 95 4A 5F `.r.y.R2.c....J_
0270: 17 A2 D7 30 0D 06 09 2A 86 48 86 F7 0D 01 01 0B ...0...*.H......
0280: 05 00 03 82 01 01 00 40 DA 72 E6 EB DF 04 8C 0C .......@.r......
0290: 33 E5 98 91 9F 23 4A B0 11 EB 73 52 BB 58 3A 16 3....#J...sR.X:.
02A0: 0C A2 AE A6 6C 3D DD D3 07 65 52 7E 34 DE 3C F0 ....l=...eR.4.<.
02B0: FB D1 7A 5C 12 15 10 EE 86 ED 3F 19 15 1E 98 3B ..z\......?....;
02C0: 3E 1B 22 AF 2F 8C 8F 4C 86 F9 A0 E3 FA A2 09 0B >."./..L........
02D0: 43 9C 63 7B 86 AD BF EA 3E 8E 78 8A 2B 4E 37 1C C.c.....>.x.+N7.
02E0: E8 2F C7 BC A8 24 50 2F AF D5 DA 1C 89 DE F9 2D ./...$P/.......-
02F0: 83 6F A4 19 F7 D0 C7 85 CD 81 0F 6E 35 A6 74 6C .o.........n5.tl
0300: 60 2F 6B 9D B5 F3 EF 5E CA 53 96 E9 E9 A9 CC 0B `/k....^.S......
0310: 7D DC E3 DE B3 E8 45 11 AB BD 53 6A A6 D6 6A 1B ......E...Sj..j.
0320: 2D 55 17 55 41 EE 11 A7 FC 11 68 F4 21 42 FC 47 -U.UA.....h.!B.G
0330: 62 5A 48 DD 76 42 CB 17 9B 2F EF 4B 43 41 B9 39 bZH.vB.../.KCA.9
0340: DD A1 36 FB 90 59 62 FA FA A5 78 97 57 8A 8C 7F ..6..Yb...x.W...
0350: 5D 4C C8 09 B8 6D 60 D7 AC A3 72 05 11 60 0F 12 ]L...m`...r..`..
0360: 42 7A 48 57 05 CA 7E 90 2B 1A 3E BE 65 FC 7B 84 BzHW....+.>.e...
0370: 48 D5 4A BE 44 1C D5 10 08 BC 3A 52 47 AF 9F 55 H.J.D.....:RG..U
0380: 01 95 77 60 EF D9 D6 0C 00 01 49 03 00 17 41 04 ..w`......I...A.
0390: 8A 0E A5 C9 84 A9 48 ED 7E 02 87 32 7A 88 5B 4D ......H....2z.[M
03A0: 3F AC CC 86 9A 6E F4 86 17 5A 2D 99 BA 4D 36 F2 ?....n...Z-..M6.
03B0: A0 BF FE 75 0D 84 02 80 F0 41 44 82 04 33 30 B2 ...u.....AD..30.
03C0: 00 AE 6F 53 95 D9 C1 41 D8 90 F0 D5 F1 54 AB 18 ..oS...A.....T..
03D0: 04 01 01 00 1B EB 30 F7 0A 78 47 32 1D 9E 60 8F ......0..xG2..`.
03E0: 98 F6 D2 37 21 0D C0 D8 51 1C 6B 2A 53 BE 1B A4 ...7!...Q.k*S...
03F0: AF 57 B2 15 05 F8 DC 26 14 81 7A 64 CF D8 1D 64 .W.....&..zd...d
0400: 01 32 2D A5 CA ED DA 2B A5 5C C8 FE 5E 00 9A E2 .2-....+.\..^...
0410: 5F 64 7F 64 0B 37 86 0F D8 3F F9 C1 46 C4 32 35 _d.d.7...?..F.25
0420: 5F 98 25 3C 12 3A 9B D9 4F 9C 9A 3F A7 75 AC 9A _.%<.:..O..?.u..
0430: EC 43 8B 42 3D EB 12 8E 65 A9 1F 46 B1 13 73 8F .C.B=...e..F..s.
0440: A4 98 7B 0C D4 A9 41 3F F4 80 20 8D C5 30 42 C5 ......A?.. ..0B.
0450: 9F EC B8 37 AA E9 BC 2F 09 EC DB 50 AB 84 6B BB ...7.../...P..k.
0460: A2 E4 4D 45 C0 0F 14 37 6C 80 18 04 20 AD 4E 05 ..ME...7l... .N.
0470: 35 1F 4F 35 A4 3C 80 B2 A9 66 17 EF 22 B1 48 3C 5.O5.<...f..".H<
0480: DA 70 57 28 BC AA 81 E1 AB B3 BE 33 A0 3A E5 E8 .pW(.......3.:..
0490: 10 62 A0 25 05 DC 7D 4F C0 1D 7B C5 1E 62 65 4E .b.%...O.....beN
04A0: 15 5E 7B AA 47 11 8C 92 39 2F E8 CB E2 8C 91 C7 .^..G...9/......
04B0: A1 72 E6 35 23 EC 4E 4C EB 92 8F B9 84 1F C7 31 .r.5#.NL.......1
04C0: 83 62 D3 87 2D 34 25 87 E4 D0 21 D3 DC FB 4D A9 .b..-4%...!...M.
04D0: 6B 85 49 23 0E 00 00 00 k.I#....
[Raw read]: length = 5
0000: 16 03 03 00 46 ....F
[Raw read]: length = 70
0000: 10 00 00 42 41 04 10 45 C4 6E 23 4A B8 FB 6C 76 ...BA..E.n#J..lv
0010: 8F 63 44 03 FA 01 42 DE 24 0F 5B 65 E1 AC 8C 68 .cD...B.$.[e...h
0020: BD 4A 92 0D 84 A2 54 0C B7 12 8C 50 B9 FB 46 B8 .J....T....P..F.
0030: 16 6B 4B 74 AE 94 71 F2 37 BC E2 2D F6 38 60 9A .kKt..q.7..-.8`.
0040: 6E D8 17 6B E0 31 n..k.1
NioProcessor-2, READ: TLSv1.2 Handshake, length = 70
*** ECDHClientKeyExchange
ECDH Public value: { 4, 16, 69, 196, 110, 35, 74, 184, 251, 108, 118,
143, 99, 68, 3, 250, 1, 66, 222, 36, 15, 91, 101, 225, 172, 140, 104,
189, 74, 146, 13, 132, 162, 84, 12, 183, 18, 140, 80, 185, 251, 70, 184,
22, 107, 75, 116, 174, 148, 113, 242, 55, 188, 226, 45, 246, 56, 96,
154, 110, 216, 23, 107, 224, 49 }
SESSION KEYGEN:
PreMaster Secret:
0000: 3D FC 26 93 B7 20 38 87 37 1E 63 34 88 83 9C 28 =.&.. 8.7.c4...(
0010: 1C FC 96 8E A6 B7 AB CA 5F 1B 6B 19 A3 C5 53 B4 ........_.k...S.
CONNECTION KEYGEN:
Client Nonce:
0000: 70 30 AF 6C 3B C6 C5 88 4E 17 F8 94 6E 6C D4 67 p0.l;...N...nl.g
0010: B6 81 A0 B4 D7 CF 06 34 C3 0A B0 B2 BE 32 14 2A .......4.....2.*
Server Nonce:
0000: 59 FF 7D 2B 81 E0 DF 32 22 98 18 D7 B2 9C 4A C3 Y..+...2".....J.
0010: B0 94 C0 4A 84 B2 22 0F FB 75 A1 36 BC AF 97 92 ...J.."..u.6....
Master Secret:
0000: 9D 6E 37 E4 84 07 34 64 D0 3E D7 50 CF 2F 61 8B .n7...4d.>.P./a.
0010: 0A 11 28 F0 49 7D 4B 2E 6A D8 CF 9B 53 89 69 F1 ..(.I.K.j...S.i.
0020: E7 FB 97 45 38 9E EE CD A6 DF 5B 16 2B 95 76 52 ...E8.....[.+.vR
... no MAC keys used for this cipher
Client write key:
0000: 94 DE 29 10 EF 61 73 63 33 FD 5E AA 81 9D 31 02 ..)..asc3.^...1.
Server write key:
0000: 29 AA 39 30 71 B1 21 16 DE 1A 0E FD 08 13 1F FF ).90q.!.........
Client write IV:
0000: 0B E6 92 C4 ....
Server write IV:
0000: EB CE D4 E3 ....
[read] MD5 and SHA1 hashes: len = 70
0000: 10 00 00 42 41 04 10 45 C4 6E 23 4A B8 FB 6C 76 ...BA..E.n#J..lv
0010: 8F 63 44 03 FA 01 42 DE 24 0F 5B 65 E1 AC 8C 68 .cD...B.$.[e...h
0020: BD 4A 92 0D 84 A2 54 0C B7 12 8C 50 B9 FB 46 B8 .J....T....P..F.
0030: 16 6B 4B 74 AE 94 71 F2 37 BC E2 2D F6 38 60 9A .kKt..q.7..-.8`.
0040: 6E D8 17 6B E0 31 n..k.1
[Raw read]: length = 5
0000: 14 03 03 00 01 .....
[Raw read]: length = 1
0000: 01 .
NioProcessor-2, READ: TLSv1.2 Change Cipher Spec, length = 1
[Raw read]: length = 5
0000: 16 03 03 00 28 ....(
[Raw read]: length = 40
0000: 00 00 00 00 00 00 00 00 7D 86 B7 4E 45 C2 D3 95 ...........NE...
0010: CC 5F 4D ED 0F C8 2F 1D B9 55 E9 16 C6 C8 E1 A4 ._M.../..U......
0020: DB 3C F8 99 C4 54 4A F3 .<...TJ.
NioProcessor-2, READ: TLSv1.2 Handshake, length = 40
Padded plaintext after DECRYPTION: len = 16
0000: 14 00 00 0C 43 87 CE B2 F7 27 29 23 EB EF 7A E6 ....C....')#..z.
*** Finished
verify_data: { 67, 135, 206, 178, 247, 39, 41, 35, 235, 239, 122, 230 }
***
[read] MD5 and SHA1 hashes: len = 16
0000: 14 00 00 0C 43 87 CE B2 F7 27 29 23 EB EF 7A E6 ....C....')#..z.
NioProcessor-2, WRITE: TLSv1.2 Change Cipher Spec, length = 1
*** Finished
verify_data: { 148, 152, 55, 120, 76, 44, 191, 5, 179, 120, 230, 155 }
***
[write] MD5 and SHA1 hashes: len = 16
0000: 14 00 00 0C 94 98 37 78 4C 2C BF 05 B3 78 E6 9B ......7xL,...x..
Padded plaintext before ENCRYPTION: len = 16
0000: 14 00 00 0C 94 98 37 78 4C 2C BF 05 B3 78 E6 9B ......7xL,...x..
NioProcessor-2, WRITE: TLSv1.2 Handshake, length = 40
%% Cached server session: [Session-13,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
[Raw write]: length = 6
0000: 14 03 03 00 01 01 ......
[Raw write]: length = 45
0000: 16 03 03 00 28 00 00 00 00 00 00 00 00 4E 35 29 ....(........N5)
0010: E4 06 DD 74 40 D2 2C 13 7C FD 55 DB 6F E0 8F 32 ...t@.,...U.o..2
0020: 41 08 53 42 75 FE 6C 03 CD 64 A8 8A C9 A.SBu.l..d...
On 05/11/17 00:02, Emmanuel Lécharny wrote:
> Le 04/11/2017 à 19:57, Jason a écrit :
>> If you are using the auto generated self signed certificates try a version
>> 1.7 jvm or generate your own certs. I think the DS selfsigned certs are not
>> created correctly in a 1.8 Jvm due to changes in supported crypto
>> algorithms.
> You can change the self-signed certificate. It's provided for
> convenience only.
>
> We may generate a new one for Java 8 in a later release.
>
Re: apache DS + thunderbird : issue with TLS, while clear is
functional
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 04/11/2017 à 19:57, Jason a écrit :
> If you are using the auto generated self signed certificates try a version
> 1.7 jvm or generate your own certs. I think the DS selfsigned certs are not
> created correctly in a 1.8 Jvm due to changes in supported crypto
> algorithms.
You can change the self-signed certificate. It's provided for
convenience only.
We may generate a new one for Java 8 in a later release.
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: apache DS + thunderbird : issue with TLS, while clear is functional
Posted by Jason <ja...@gmail.com>.
If you are using the auto generated self signed certificates try a version
1.7 jvm or generate your own certs. I think the DS selfsigned certs are not
created correctly in a 1.8 Jvm due to changes in supported crypto
algorithms.
On 4 Nov. 2017 9:37 pm, "Emmanuel Lécharny" <el...@gmail.com> wrote:
>
>
> Le 03/11/2017 à 23:50, Serge Pouliquen a écrit :
> > Hi,
> >
> > > Can you packet capture from one end or the other and verify that the
> > secure handshake is successful or failing when you have TLS enabled?
> >
> > I'm not sure to well understand the request, but I will try to answer.
> > > from one end or the other
> > run on localhost, so it should be the same
> > I indicated in point 6, that I captured nothing (no communication) :
> > no TLS request, no success, no TLS failure.
> > Once a request has been send by address book window, I can capture TLS
> > handshake success and the result of the search.
> > Later search from compose window, I can see TLS success and the result
> > are proposed in completion list.
> >
> > When thunderbird is not completing, wireshark on loopback capture no
> > packet at all.
> >
> > I find that a bit strange.
>
> Indeed.
>
> >
> >
> > > -Djavax.net.debug=all
> > tried and no log at the moment a request should be issued
>
> You don't see anything in the ApacheDS logs ? That may mean TB is not
> sending anything...
> >
> > software versions :
> > apache ds : 2.0.0-M24
> > thunderbird : 52.4.0 (packaged by debian for strech amd64)
> > java version : openjdk 1.8.0_151 (packaged by debian for strech amd64)
>
> Latest versions. Fine.
> >
> > java -version
> > openjdk version "1.8.0_151"
> > OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-1~deb9u1-b12)
> > OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
> >
> > Should I test the oracle version ?
>
> That woudl worth the try. Not sure it will change anything.
>
> OTOH, you do not seems to be the only one having this problem :
> https://stackoverflow.com/questions/28990729/tls-support-for-ldap-in-
> thunderbird
>
> You may want to activate Thuderbird logs :
>
> https://wiki.mozilla.org/MailNews:Logging
>
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>
Re: apache DS + thunderbird : issue with TLS, while clear is
functional
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 03/11/2017 à 23:50, Serge Pouliquen a écrit :
> Hi,
>
> > Can you packet capture from one end or the other and verify that the
> secure handshake is successful or failing when you have TLS enabled?
>
> I'm not sure to well understand the request, but I will try to answer.
> > from one end or the other
> run on localhost, so it should be the same
> I indicated in point 6, that I captured nothing (no communication) :
> no TLS request, no success, no TLS failure.
> Once a request has been send by address book window, I can capture TLS
> handshake success and the result of the search.
> Later search from compose window, I can see TLS success and the result
> are proposed in completion list.
>
> When thunderbird is not completing, wireshark on loopback capture no
> packet at all.
>
> I find that a bit strange.
Indeed.
>
>
> > -Djavax.net.debug=all
> tried and no log at the moment a request should be issued
You don't see anything in the ApacheDS logs ? That may mean TB is not
sending anything...
>
> software versions :
> apache ds : 2.0.0-M24
> thunderbird : 52.4.0 (packaged by debian for strech amd64)
> java version : openjdk 1.8.0_151 (packaged by debian for strech amd64)
Latest versions. Fine.
>
> java -version
> openjdk version "1.8.0_151"
> OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-1~deb9u1-b12)
> OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
>
> Should I test the oracle version ?
That woudl worth the try. Not sure it will change anything.
OTOH, you do not seems to be the only one having this problem :
https://stackoverflow.com/questions/28990729/tls-support-for-ldap-in-thunderbird
You may want to activate Thuderbird logs :
https://wiki.mozilla.org/MailNews:Logging
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: apache DS + thunderbird : issue with TLS, while clear is
functional
Posted by Serge Pouliquen <sp...@free.fr>.
Hi,
> Can you packet capture from one end or the other and verify that the
secure handshake is successful or failing when you have TLS enabled?
I'm not sure to well understand the request, but I will try to answer.
> from one end or the other
run on localhost, so it should be the same
I indicated in point 6, that I captured nothing (no communication) : no
TLS request, no success, no TLS failure.
Once a request has been send by address book window, I can capture TLS
handshake success and the result of the search.
Later search from compose window, I can see TLS success and the result
are proposed in completion list.
When thunderbird is not completing, wireshark on loopback capture no
packet at all.
I find that a bit strange.
> -Djavax.net.debug=all
tried and no log at the moment a request should be issued
software versions :
apache ds : 2.0.0-M24
thunderbird : 52.4.0 (packaged by debian for strech amd64)
java version : openjdk 1.8.0_151 (packaged by debian for strech amd64)
java -version
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-1~deb9u1-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
Should I test the oracle version ?
Thanks
Serge
On 03/11/17 23:24, Emmanuel Lécharny wrote:
>
> Le 03/11/2017 à 21:22, Lohr, Donald a écrit :
>> Can you packet capture from one end or the other and verify that the
>> secure handshake is successful or failing when you have TLS enabled?
> Anoher thing to do is to start ApacheDS with -Djavax.net.debug=all
> (beware this is going to be verbose).
>
> If there is some issue during the handshake, you'lle get some
> information about what's going wrong.
>
> Also please provide the ApacheDS and TB version you are using, and the
> Java version for the server. You might have some cipher limitation that
> need to be dealt with (some ciphers might be forbiden. You might also
> have to install JCE.
>
Re: apache DS + thunderbird : issue with TLS, while clear is
functional
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 03/11/2017 à 21:22, Lohr, Donald a écrit :
> Can you packet capture from one end or the other and verify that the
> secure handshake is successful or failing when you have TLS enabled?
Anoher thing to do is to start ApacheDS with -Djavax.net.debug=all
(beware this is going to be verbose).
If there is some issue during the handshake, you'lle get some
information about what's going wrong.
Also please provide the ApacheDS and TB version you are using, and the
Java version for the server. You might have some cipher limitation that
need to be dealt with (some ciphers might be forbiden. You might also
have to install JCE.
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: apache DS + thunderbird : issue with TLS, while clear is
functional
Posted by "Lohr, Donald" <lo...@jmu.edu>.
Can you packet capture from one end or the other and verify that the
secure handshake is successful or failing when you have TLS enabled?
D
On 11/03/2017 04:00 PM, Serge Pouliquen wrote:
>
>
> Hi,
>
> I'm using apache DS embedded in a java app in order to store my
> address book.
> My thunderbird is configured to complete addresses only with that ldap
> server (not with local adress book).
> When I use it without TLS, it is completely functional.
> When I use TLS, I cannot complete address from compose window until I
> made a request to ldap server from address book window.
>
> 1/ Once I made one request from address book window, I got address
> completion from compose window
> 2/ I can stop and start thunderbird, I still have completion.
> 3/ I don't have any firewall
> 4/ url is based on localhost and certificate is acceptable (tested
> fine with address book window)
> 5/ I can reproduce on linux (debian stretch) and on windows 10 (client
> and software on the same machine)
> 6/ on linux, with wireshark, when compose window is not completing
> addresses, there is no traffic at all (on loopback)
>
> Is someone aware of something similar ?
> Have you any idea of workaround ? (go to address book window in order
> to make one request is not really acceptable)
>
> I don't have any good reason to think apache ds is culprit (because
> looks good from adress book window).
> I hope ldap is quite functional feature in thunderbird.
>
> For particular reason, I will appreciate to switch from clear to TLS.
>
> Thanks for apache ds software
> Regards
> Serge
>
--
D o n a l d L o h r
I n f o r m a t i o n S y s t e m s
J a m e s M a d i s o n U n i v e r s i t y
5 4 0 . 5 6 8 . 3 7 3 0