Lots of TLS errors: cannot receive mail from some servers

dagservice

Verified User
Joined
Aug 27, 2015
Messages
11
Good afternoon,

We're getting reports that we cannot receive e-mail from some senders. After investigation, the logs keep showing the following message for the failing domains:
Code:
TLS error on connection from sender-server.com [123.123.123.123] (SSL_accept): error:1417D102:SSL routines:tls_process_client_hello:unsupported protocol

Searching via google, i found a thread suggesting that this may be due to some SSL versions not being accepted, but there's not solution listed there and it's for postfix. If i connect using
Code:
openssl s_client -starttls smtp -crlf -connect mail.myserver.com:587
, it does connect, but
Code:
dagservice@Monster:~$ openssl s_client -starttls smtp -crlf -connect mail.myserver.com:587 -ssl3
CONNECTED(00000003)
140220228961952:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:599:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 266 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1588593473
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

Same for example with -tls1

Relevant information:
Exim 4.93.0.4 running on ubuntu 16.04, all recent updates installed. Directadmin version 1.60.4.
 
DA does not work with postfix.
It's probably because TLS < 1.2 is not supported anymore by default.

Explained here and there is a workaround for it which also can be found here:

I don't know if you need this:

Best is to tell your customers to update their email clients to use TLS 1.2.

Again, the above is for Exim, DA does not use Postfix.
 
Thank you for your insights. I made a temporary fix by setting
Code:
tls_advertise_hosts = !12.34.56.78:!23.45.67.89:*
(fictional IP adresses inserted)

That should encourage the outdated servers to set up a plaintext connection to avoid issues, which appears to work.
 
Thanks for this post, this also solved an issue I had with a 3rd party SPAM filtering provider (Greenview Data) which started on Saturday morning when they changed TLS requirements on their end.

I'm waiting to hear back from them in terms of what cipher they actually need on our end to negotiate TLS correctly. I'm going to make a new post about this to see what insight the forum has on this issue. Thanks again!

tls_advertise_hosts = !12.34.56.78:!23.45.67.89:* is what did the trick and allowed mail to start flowing again.
 
Before you switch to old stuff like TLS 1.0 and SSL3, I also see this error if the DSE ciphers are gone.

Try this via SSH:
nmap --script ssl-enum-ciphers -p 465 localhost

Check if these ciphers are missing, you might only see the ECDHE keys, not the DHE like displayed here:
Code:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong

if these are missing, first try to request a new hostname certificate manually like this:
Code:
cd /usr/local/directadmin/scripts
./letsencrypt.sh request_single your.hostname.com 4096

After that, you should have these cipers. Check if things work again.

If not, then you could use the solution on Poralix site to an ancient unsafe situation. But it would be better to advise the customer to update to modern safer solutions for their mail.
 
Thanks Richard, that seemed to do the trick. Still need to monitor things overnight but, so far in my testing, it's working. I'll have to see if the SPAM provider's queue starts filling and if I see the log entries again but... I sent a test email and it came through immediately form Gmail, through the SPAM filter provider and on to my mailbox on DA. AND... No TLS error in the Exim log. So far so good.

No I'm off to figure out why I have so many of these

TLS error on connection from localhost [127.0.0.1] SSL_accept: TCP connection closed by peer

I did a test login to Roundcube thinking maybe it was Roundcube but nope, it works fine.

Any idea what is connecting locally like this causing TLS errors? Hmmm Maybe I should create separate post for this one. It doesn't appear anything is broke exactly but, these entries are concerning. Obviously something is trying to connect from localhost and failing. Maybe a PHP script or Wordpress or something??

In any case, thank you again for your help Richard, you have been a huge help to me lately.
 
Also, I do use LetsEncrypt on different servers but without DA and I get how to use that and how auto-renew works. I also use it on DA on some servers but I'm still a little, umm lacking in LetsEncryt knowledge so..

Can you tell me if the LetsEncrypt command I ran based on your suggestion that resulted in a new cert being generated, will require me to renew it manually within 90 days? Will it auto-renew? I already had a cert for the server hostname I setup when I setup this DA server but I don't remember what the deal was with auto-renewing it etc. So.. I thought I would ask if I need to worry about renewing it or if it will auto-renew. Thanks.
 
Can you tell me if the LetsEncrypt command I ran based on your suggestion that resulted in a new cert being generated, will require me to renew it manually within 90 days? Will it auto-renew?
It will auto-renew, however, at this moment there is a bug going on which I mentioned on the forums and in a ticket.
John had been working hard on it this week to fix this issue.

Problem was that on auto-renew of the hostname, the ciphers went back to ECDSE and lost the DSE again. John has found the cause and fixed the issue the day before yesterday. You can switch to alpha channel binaries to have it fixed now, or wait until the next current channel release which will also take not very long.
 
Code:
TLS error on connection from sender-server.com [123.123.123.123] (SSL_accept): error:1417D102:SSL routines:tls_process_client_hello:unsupported protocol


For those, who might find the thread in Google. There is a new cause of the same error recently discovered by me.

Some old mail servers which communicate with yours might not like modern EC 256 bits (SHA256withECDSA) and longer keys, hence the error might occur.

So you will need to re-create a certificate for a hostname at least. If you use free certificates from Let's Encrypt, then run the following command as root:

Code:
/usr/local/directadmin/scripts/letsencrypt.sh request $(hostname -f) 4096

Give a couple of minutes to services to restart, and then try sending an email. If it does not help, then check the further instructions.
 
For those, who might find the thread in Google. There is a new cause of the same error recently discovered by me.

Some old mail servers which communicate with yours might not like modern EC 256 bits (SHA256withECDSA) and longer keys, hence the error might occur.
I already discovered that last year when having issues with HP printers.

Also several topics form mailservers giving this issue were answered to request a new hostname certificate as a solution because of the DSA keys which were not present. ;)
So it's not something new as far as I can see.
/usr/local/directadmin/scripts/letsencrypt.sh request $(hostname -f) 4096
Shouldn't that be:
request_single?
 
Back
Top