SMTP mail sending SSL error

NethServer Version: your_version
Module: Mail

Hi,

I have a program that can send email directly via an SMTP server.
I set it to send email via Nethsever, but it can’t send it due to an SSL error.

I configured the SMTP server in the program as follows:
SMTP server IP address: “IP address”
Port: 465
Security: SSL v2
Password: “password”

I took a screenshot of the error from /var/log/maillog.

Does anyone have an idea what the problem could be?

Thanks for the help.

Try 587 as port, please, stil SSL.
Anyway, the encryption should be TLS 1.2

Hi @steve

You probably need a valid ssl cert, eg LetsEncrypt.

Certain programming languages are rather fussy about this, among them PHP & JAVA…

My 2 cents
Andy

@pike
Same error for port 587. The program only knows TLS 1.0 version, so could this be the cause of the problem?

@Andy_Wismer
The server has a Let’s Encrypt certificate, but it applies to the public IP address and I want to send the email from the local network using SMTP. How can this cause a problem?

In my personal opinion could. I suggest to upgrade to TLS 1.2 your software. Otherwise… there’s still the TLS policy section for NethServer.

1 Like

LetsEncrypt can NEVER apply to a public IP, as LetsEncrypt only supports host or domain names…
This can be valid on internal or external pointing NICs / IPs.

So this matters very much!

And also: as LE only supports domain names, not IPs, you need to try using the servers name in your App.
TIP: Use the internal DNS of NethServer to make the App recognize the domain name / IP of your Nethserver - using SSL with LE!

However, as your App only supports TLS 1.0, it probably is too old to recognize a valid LE ssl cert…

My 2 cents
Andy

@pike
Thank you, I will consult with the developer of the program, I hope I will be successful.

@Andy_Wismer
I thought so. I tried to use the domain name in the setup, but I got the same error. In the local network, the domain name is directed to the IP address of the server, as you suggested earlier, for another reason, so I can also access the server from the browser by entering the domain name.
I think that then the problem can only be the TLS version.

Thank you for your help, I hope the problem can be solved with the program developer.

1 Like

If the deveolper is willing to cooperate, i’d suggest to go for TLS 1.3.
TLS 1.2 is currently the minimum encryption level request for public comunications.

Unfortunately, the program’s developer does not modify the program’s direct SMTP mail sending service. The program therefore only knows the TLS 1.0 version.

I modified the TLS Policy on the Nethserver, I set the 2018-10-01 Policy. This way I can send mail directly from the program, but I don’t know what security risk this poses, and whether clients can still send mail using SSL v2.x, v3 and TLS 1.2.

Can anyone help with this?

Last weekend we successfully switched to using Nethserver. It was about time. The planned two-day transition was solved in one day and everything seems to be working. At least I hope it won’t be a problem…

Thank you all for your help so far.

:thinking: is he/she/whatever planning not to sell the program anymore? I mean… TLS 1.0 is archeological (1999) and deprecated, 1.2 is not that young (2008) and the recent 1.3 is less than 4 years old, so it will take 2 years to get traction but it certainly will, according to the current international situation. Whatever. NMP.

Mr Denis Pollini had an issue with sending messages from old Synology DSM5-powered NAS to Nethserver.

solved by allowing non-encrypted relay.
If the connecition goes on a private LAN or via VPN I don’t think the solution applied here (encryption disabled) is a good one.

Can you try sending the mails in plain mode on port 25 to the Nethserver?

On the Nethserver you can enable this possibility only for the source ip (so from the ip where the porgram resides):

From cockpit → Mail → Relay → Click on “Details” → enter the source IP in “Allow relay from IP address”
Eventually put a check mark on “Enable authentication on port 25” to enable authentication.

One thought did not leave me alone. I was wondering if the SMTP mail sending works with a newer version of the dll files. I didn’t know if there was a newer version of the files, but the search yielded results.

I replaced the old dll files with the new ones and behold a miracle! SMTP mail sending works!

The two files are libeay.dll and ssleay.dll. The Windows 32-bit openssl package can be downloaded from this address:
https://indy.fulgan.com/SSL/openssl-1.0.2u-i386-win32.zip

The package must be unpacked and the two files copied to the place of use, replacing the old ones.

I hope this will be useful for anyone who encounters a similar problem and error message.

Glad you worked around the issue. However, according to openssl.org
/source/index.html

The latest stable version is the 3.0 series supported until 7th September 2026. This is also a Long Term Support (LTS) version. The previous LTS version (the 1.1.1 series) is also available and is supported until 11th September 2023. All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of support and should not be used. Users of these older versions are encouraged to upgrade to 3.0 as soon as possible. Extended support for 1.0.2 to gain access to security fixes for that version is available

Bold was added by me.

According to the blog

Our current LTS release is 1.0.2, and it will be supported until the end of 2019.

statement dated may 2018.

Anyway.
There are a lot of different 1.0.2. versions around the web.
Some reported 1.0.2k as latest, some others 1.0.2q.
According to github, the source report 1.0.2v-dev

And anyway, maybe the developer should reconsider a repack with at least openssl 3.0?

Thanks for sharing, anyway.

@pike
I completely agree with you.

I needed a quick solution and a test, so I looked for Windows binary files instead of the original ones. I didn’t have time and opportunity to compile under Windows.

Unfortunately, the programmer will not update the possibility of sending mail in the program. This is not necessary at the moment because the SSL connection works on TCP port 465 with the Nethserver default TLS Policy (2020-05-10 only TLS 1.2) and there is no need to reduce security.