Cannot start TLS: handshake failure #2185
Comments
|
I have seen this happening with a wrong MTU.
… Am 16.01.2019 um 01:53 schrieb Till ***@***.***>:
Recently i'm getting Cannot start TLS: handshake failure for gmx.de and web.de recipients. Other provider like GMail work. However there are a lot of mails to GMX and web.de apperently.
Now I'm not sure if the problem lies on my end, within mailcow or GMX/web.de and the first question is, what's the best way to debug this problem in the containers? All I get from the logs is this:
1/16/2019, 1:31:28 AM | info | SSL_connect error to mx01.emig.gmx.net[212.227.17.5]:25: Connection timed out
1/16/2019, 1:31:28 AM | info | 8BE0C60724: Cannot start TLS: handshake failure
1/16/2019, 1:31:28 AM | info | SSL_connect error to mx00.emig.gmx.net[212.227.15.9]:25: Connection timed out
1/16/2019, 1:31:28 AM | info | B980C60729: Cannot start TLS: handshake failure
1/16/2019, 1:31:27 AM | info | SSL_connect error to mx-ha02.web.de[212.227.17.8]:25: Connection timed out
1/16/2019, 1:31:27 AM | info | 5EDA56072C: Cannot start TLS: handshake failure
...only a lot more.
Since I saw a timeout I already started by installing inetutils in the postfix container to check if it basically can connect to the hosts in question and that works. So it probably really is some specific SSL/TLS problem.
The problem started with a version which was around 4 weeks ago (but the problem itself came up just recently). I now upgraded to the recent master branch and regarding SSL/TLS my postfix configuration is basically the same as in master. This problem still persists though.
Any hint to better debug this or temporally workaround (even if unsecure) would be welcome. Thanks!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Very helpful tip @andryyy thanks a lot - and this made all further troubleshooting invalid since exactly that was the problem. Our VMs got moved to a new virtual network with a MTU of 1400 two days ago... The fast solution is adding In our case we will now also check if there are better global options, which doesn't involve updatating the docker-compose files of every project. Should we find one, I will add it here. |
|
Nice! :) |
|
Same error here and the hint with mtu does not work for me any idea? part of my docker-compose.yml: Undelivered Mail Returned to Sender Message: |
|
Why do you think this is a MTU issue exactly? Just want to be sure. What is your default MTU on the primary NIC? |
I've also tried 1500 but it does also not work :( |
|
Please don't change the stacks MTU if you don't have to. It is just a TLS handshake failure then. Check if that happens with other servers, too. Perhaps you enforce TLS for this mailbox and the remote servers protocol/ciphers are just too old. |
|
It does not affect all remote mailboxes most functioning but there are some that have problems. I had just read the headline "Cannort start TLS" and thought that it might have been there. Where on my side could I accept that? (old protocol/ciphers) or where can I force TLS for a remote mailbox/domain? |
|
You should debug if that’s the problem after all. You could try to connect with OpenSSL on these ports. Also login to that mailbox via mailcow UI and see if it has encryption enforced. It would fall back to a plain session if encryption fails and no encryption was enforced. If it’s an incoming mail problem, check the certificate! If you use an external acme client, you might have missed to copy the renewed certificate. |
|
Hi Andre and is a bit confusing, here it works (same mail-to): and same host different messages: i also tried the web based client sogo and i got mailer returns... |
|
enforced-tls-smtp/smtp That’s exactly what I meant. We tightened the mandatory ciphers. You enforce TLS for that mailbox, so Postfix uses only secure protocols and ciphers and rejects if it cannot negotiate a secure channel. I don’t plan to lower mandatory encryption levels, but you can change your own setup to accept less secure protocols and ciphers, if you need to. Alternatively disable enforced TLS. |
|
Since this is outgoing mail, you can also create a TLS policy map in mailcow and override the TLS level requirement for that domain. |
3 tasks
|
I know this is an older issue, but still stumbled over it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Recently i'm getting
Cannot start TLS: handshake failurefor gmx.de and web.de recipients. Other provider like GMail work. However there are a lot of mails to GMX and web.de apperently.Now I'm not sure if the problem lies on my end, within mailcow or GMX/web.de and the first question is, what's the best way to debug this problem in the containers? All I get from the logs is this:
...only a lot more.
Since I saw a timeout I already started by installing inetutils in the postfix container to check if it basically can connect to the hosts in question and that works. So it probably really is some specific SSL/TLS problem.
The problem started with a version which was around 4 weeks ago (but the problem itself came up just recently). I now upgraded to the recent master branch and regarding SSL/TLS my postfix configuration is basically the same as in
master. This problem still persists though.Any hint to better debug this or temporally workaround (even if unsecure) would be welcome. Thanks!
The text was updated successfully, but these errors were encountered: