No, no certificate in thunderbird.
Work fine when running CentOS 7.3, laptop that still runs 7.3 works fine.
I'm going to attempt building the CentOS 7.3 thundirbird src.rpm in 7.4 and see if that fixes it, and if it does, file a bug report with rhel.
On 09/26/2017 01:17 AM, Peter Chiochetti wrote:
Hello Micheal,
this reminds me of something, that I experienced in the past. Why would the server! complain "Unknown CA"? To test inspect the communication with wireshark and look if the client sends a cert; or:
$ echo "a001 LOGOUT" | openssl s_client -msg -connect your.server:993
and grep for "CertificateRequest".
Do you have a certificate configured in your mailclient Thunderbird but not in Evolution?
HTH Peter
Am 2017-09-26 um 00:08 schrieb Michael A. Peters:
Definitely client issue, connecting via evolution works just fine.
So I suppose it is off the the thunderbird list. I like thunderbird better.
Only plugin I use is dkim validator and when I started thunderbird w/o extensions - still had same issue.
But I think it is definitely not a dovecot problem.
On 09/25/2017 01:49 PM, Michael A. Peters wrote:
I'm not running any A/V software, and the same version of dovecot on servers with CA signed certs (komodo) - the client connects to them just fine.
On 09/25/2017 01:40 PM, Tony wrote:
It does look like a client issue. Do you also have some kind of AV running? There are some AV software that can sometimes interfere with mail sessions. See if you might be running into a similar situation: https://support.mozilla.org/en-US/questions/1066126
Cheers,
TC
On 9/25/17 1:27 PM, Michael A. Peters wrote:
I use dovecot on several servers. One of them uses a self-signed cert, it's just me.
It worked fine until yesterday when I upgraded my desktop (NOT the server) to CentOS 7.4
Now thunderbird complains when it starts up, and won't let me confirm the security exception.
On the server the following error occurs in the log:
Sep 25 20:17:49 librelamp dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=2600:1010:b064:f260:e83e:562d:2316:18df, lip=2600:3c01::f03c:91ff:fee4:310c, TLS handshaking: SSL_accept() failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca: SSL alert number 48, session=<u7agQAlasK8mABAQsGTyYOg+Vi0jFhjf>
I believe this is a client issue, as it worked just fine in CentOS 7.3 client, but I am hoping this has been seen and fixed before