After update to version 0.5, I can't send email any more without TLS error to my MiaB

[Benoit]

Sending the email to the following server failed : my_email_box.com:587
Could not convert socket to TLS
Received fatal alert: protocol_version

[latinhypercube]

Have you checked the certificate status page on the admin menu? Any clues there?

Also, you can rerun the mailinabox setup script. That can clear these problems from some reports I’ve seen.

[eeeee]

@Benoit

Sending the email to the following server failed : my_email_box.com:587

it is wise to fix the output of this instruction:

Dig web interface - online dns lookup tool.

it seems like your 2. level domain is not connected properly or something!

[Benoit]

Thanks eeeee,
on the real email domain, we have a ns1, ns2…

[Benoit]

@latinhypercube

Have you checked the certificate status page on the admin menu? Any clues there?

Also, you can rerun the mailinabox setup script. That can clear these problems from some reports I’ve seen.

Thanks Latin, yes the certificate is still good:TLS (SSL) certificate is signed & valid. The certificate expires in 71 days on 2021-03-03. even if not valid for long

I’ll do the setup script again (when time free) and will keep posted.

[latinhypercube]

I assume the message is from a mail user agent trying to send email through your MIAB server.

You might also try changing the password on the relevant user account; there are sometimes minor configuration issues there on upgrade from what I’ve seen.

[Benoit]

Hi Latin,
I have done this test of creating a new temporary mailbox with easy password to verify this point and it stay with the same connectivity message:
Could not convert socket to TLS
Received fatal alert: protocol_version

I tried again the upgrade

curl -s https://mailinabox.email/setup.sh | sudo bash

and got this error:

FAILED: add-apt-repository -y ppa:certbot/certbot

Error: retrieving gpg key timed out.

Strange
Doing again the update to verify…
Seems better:

Primary Hostname: =host=
Public IP Address: =ip=
Mail-in-a-Box Version: v0.51

Updating system packages…
Installing system packages…
Initializing system random number generator…
Firewall is active and enabled on system startup
Installing nsd (DNS server)…
Installing Postfix (SMTP server)…
Installing Dovecot (IMAP server)…
Installing OpenDKIM/OpenDMARC…
Installing SpamAssassin…
Installing Nginx (web server)…
Installing Roundcube (webmail)…
Installing Nextcloud (contacts/calendar)…
Nextcloud is already latest version
Installing Z-Push (Exchange/ActiveSync server)…
Installing Mail-in-a-Box system management daemon…
Installing Munin (system monitoring)…
updated DNS: OpenDKIM configuration

---

Your Mail-in-a-Box is running.

Please log in to the control panel for further instructions at:

=link=

If you have a DNS problem put the box’s IP address in the URL
(=link= but then check the TLS fingerprint:
=fingerprint=

but at the end, again a failure:

Sending the email to the following server failed : =host=:587

Could not convert socket to TLS

Received fatal alert: protocol_version

---

[latinhypercube]

Are you able to log in to the email account via the web interface (Roundcube)? Able to send email from there?

Looking at the error message further it seems to be complaining about TLS version. MIAB now publishes a policy over https but it also still supports old TLS versions.

What is the mail user agent? Outlook perhaps?

Is MIAB your DNS server or is that external? Have a look at some of the forum posts on ‘MTA STS’ policy for some other considerations.

This post might be useful: [SOLVED] V0.50 MTA-STS policy is missing: STSFetchResult.NONE

[Benoit]

It is very strange:

1. I can log in Web mail, and send and recieve emails
2. I can send and receive email in IMAP using outlook client
3. I was able to send an email to openssl s_client -starttls smtp -connect =mailserver=:587 with success
4. The client currently failing was working before the upgrade of mailinabox from 0.4 to 0.51
5. If I force it to send on port 25, it works but I get most of the time a “Relay access denied” because of non secure sending
6. When I use TLS :587, I always get the error:

Sending the email to the following server failed : =mailserver=:587
Could not convert socket to TLS
Received fatal alert: protocol_version

I have seen this solution and I try to implement it

[SOLVED] V0.50 MTA-STS policy is missing: STSFetchResult.NONE

This error occurred after an upgrade process on our servers. Find below a step by step we used to fix the problem. upgrade Login to server via SSH (putty for windows) sudo apt-get update && sudo apt-get upgrade reboot Login to server via SSH (putty for windows) curl -s https://mailinabox.email/setup.sh | sudo bash Answer questions Provision the certificates from Lets Encrypt Select [System] menu (Top Menu) Select TLS (SSL) Certificates Select [Reprovision] button upgrade again. Login …

I am blocked on:

• Select TLS (SSL) Certificates
• Select [Reprovision] button

There is no “reprovision” button on version 0.51, only a replacement for a paid one, or wait:

All certificates will be automatically renewed through [Let’s Encrypt] 14 days prior to expiration.

So, How can I force Let’s Encrypt certificate to be renewed?

[latinhypercube]

You could run the /root/management/ssl_cerficates.py script on your MIAB box I believe. (Assuming you installed as ‘root’ user)

[Benoit]

Nop. the “management” directory is to prepare the data for the web view and does not run as is.

python3 ./management/ssl_certificates.py
Traceback (most recent call last):
File “./management/ssl_certificates.py”, line 686, in
provision_certificates_cmdline()
File “./management/ssl_certificates.py”, line 381, in provision_certificates_cmdline
from exclusiveprocess import Lock
ModuleNotFoundError: No module named ‘exclusiveprocess’

[latinhypercube]

My mistake. I thought there was a script in the tools folder previously but seems I’m wrong.

[Benoit]

There is a TLS script in tests directory, but it does not work:

Test/tls.py errors

Having issues with TLS connection from external system since I have updated the MiaB from 0.40 to 0.51, I try the test tls py, but it seems not working: python3 tests/tls.py Usage: python3 tls.py [–proxy ssh_host] hostname python3 tests/tls.py =host= PORT 25 Traceback (most recent call last): File “tests/tls.py”, line 152, in sslyze(["–starttls=smtp"], 25, MOZILLA_CIPHERS_OLD) File “tests/tls.py”, line 91, in sslyze out = subprocess.check_output([SSLYZE] + common_opts + opts + [conne…

I did open another topic on this point

[alento]

@Benoit

There is no “reprovision” button on version 0.51, only a replacement for a paid one, or wait:

How long have you waited??? I have seen it take up to 24 hours for the changes to happen that call for the ssl cert to be reissued. It seems that the process is not an instantaneous one in many cases. I still have not fully explored MTA-STS so I cannot explain why this is yet, but it is behavior I have come across dealing with issues in Slack.

@Benoit
ETA: Your issue has absolutely nothing to do with MTA-STS so this entire reply does not apply.

[Benoit]

I am trying to debug this TLS problem since last friday - 5 days.
I am convinced that the issue is on MiaB as I have 5 systems that are sending notifications emails to the same MiaB and this is not working since I upgrade MiaB fro 0.4 to 0.51.

Sending the email to the following server failed : =mailserver=:587
Could not convert socket to TLS
Received fatal alert: protocol_version

What I have seen on others thread is I need to “force” the re-issue" of certificate and try to re-install
At this moment the mail server is useless for me as it does not accept emails in TLS

[alento]

@Benoit

What I have seen on others thread is I need to “force” the re-issue" of certificate and try to re-install
At this moment the mail server is useless for me as it does not accept emails in TLS

Both statements are incorrect.

@Benoit

What I have seen on others thread is I need to “force” the re-issue" of certificate and try to re-install

This actual statement is not related to your issue. From your OP, it was not discernible whether you were talking about incoming or outgoing email. Your statement was about a different mail server, not MiaB - so you got incorrect suggestions. However, now that it is clear what the issue is from another thread… the culprit has been identified.

@Benoit

At this moment the mail server is useless for me as it does not accept emails in TLS

This statement is blatantly incorrect. MiaB absolutely accepts emails in TLS. It does not, however accept emails sent by email servers/clients using outdated insecure versions of TLS (TLS1 and TLS1.1).

[alento]

@Benoit

I am convinced that the issue is on MiaB as I have 5 systems that are sending notifications emails to the same MiaB and this is not working since I upgrade MiaB fro 0.4 to 0.51.

Yes, the underlying issue you are experiencing is an indirect result of upgrading MiaB, however it is not an MiaB issue. You do not offer any detail of what these ‘5 systems’ are, but I will venture a guess that they are all using the same system… I will further guess that they all are outdated - using an older insecure version of TLS. You need for these systems to be updated to use TLS 1.2 and your problem will be solved. If for some reason these systems cannot be updated (older printers, for instance) there are methods for the devices to send to a relay which will then send the mails on to MiaB.

[latinhypercube]

Well spotted. I assumed that a mail user agent (eg Outlook) was failing to connect and that it would use TLS 1.2 at minimum.

[Benoit]

@alento

iaB absolutely accepts emails in TLS. It does not, however accept emails sent by email servers/clients using outdated insecure versions of TLS (TLS1 and TLS1.1).

Hi @alento, I agree that some statements are wrong.
I can send email to MiaB using openssl in TLS 1.2

@alento

I will further guess that they all are outdated

But this statement is also incorrect. The sender is also up-to-date and send TLS1.2

[alento]

@Benoit

But this statement is also incorrect. The sender is also up-to-date and send TLS1.2

Ok, then it may be down to what ciphers are being used. And this unfortunately is not an area I have expertise with, though I’d love to learn. Maybe someone more familiar with that issue will chime in … in the mean time I shall do some reading over the holiday.