Hey there Scott! This error looks to be a mismatch between the supported SSL/TLS versions on this client/server and your SmarterMail environment. What I typically recommend here is downloading and installing IISCrypto from Nartac Software. Once installed on the server, open it up and press the Best Practices button, then apply and save the changes before rebooting the server. This will configure Windows (and SmarterMail) to use only the supported versions of SSL/TLS and should bring it current with the sending environment. 

Please note however, that these changes can lead to older email clients and mobile devices running into similar errors when attempting to connect, so this is something you'll want to keep an eye out for. Please let me know if that helps. Have a good one!

Doesn't seem to make any difference. What I don't get is why would it start malfunctioning like this all of the sudden when before everything had been working fine.

I'm sorry to hear that Scott. Is it possible there were security changes on the underlying network itself? I've seen similar issues when AV or Firewall products proxy the SMTP session in order to scan it. Hopefully others can offer some guidance on this one too.

No changes like that have been made. Nothing particularly interesting about the firewall the server is behind, just a ordinary Netgear and Windows Firewall on the server itself is turned off.

Hey there Scott, and sorry for the delay on this. Something that might help here is determining exactly what cipher suites are supported on the client and server side. I found a guide that includes a script to do so here:

Additionally, you can use the SSL Website Tester I've linked below (be sure to choose the option to exclude your results from their dashboard) which will allow you to compare the supported/unsupported protocols and versions for both environments as well:

Let me know what you find out! :-)

Hello, 

To add to what Kyle said you can use WireShark to find out what cipher is being suggested.

Thank you

Okay I ran the following in OpenSSL and this is what it output:

openssl s_client -connect mydomain.com:25 -tls1_2

CONNECTED(000001A0)
64D00000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:ssl\record\ssl3_record.c:355:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 210 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1634687859
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---

Here's the output from the SSL tester:

So what I don't understand is why would an email provider like Gmail even care if there was a problem with a SSL3 when I thought that was outdated and is not being used any longer.

@Scott - I think this report is showing you supporting TLS 1.0/1.1 as well but I can't see the pass/fail in the screenshot. Can you confirm? The error message itself is mentioning SSL, but I'm betting they're complaining about the TLS version more specifically. A lot of these types of errors tend to get lumped in under "SSL" though the protocol may vary. 

Edit: I figured out I can scroll over in your reply! Doh! You are supporting TLS 1.0/1.1, so thats likely what Google is complaining about. You can try running the Best Practices button on IISCrypto (https://www.nartac.com/Products/IISCrypto), saving the changes, then rebooting the Windows server environment before testing again and that should do the trick. If that doesn't work theres something else going on with the certificate or the network is passing back the wrong versions (firewall or proxy.)

So why would Google care if I also support TLS 1.0/1.1 in addition to 1.2 just as long as I support 1.2? 

That's a great question Scott. The only thing I can think of is that for some reason your server (or the underlying network) is setting the upper limit at 1.0 or 1.1, so Google never see's the 1.2. 

Oh man this sucks, I have nothing to go on to solve this. I just get the feeling it's a problem with these Let's Encrypt certificates.

So if you're saying the underlying network is preventing TLS 1.2 why would the test tool see it and not Google? Could a bad Comcast Business modem cause something like this? Literally nothing has changed on my server or any of my network hardware. This is becoming a real problem since I can't get all of my mail along with a few other domains I manage for other people for almost a week now.

@Scott - It isn't preventing TLS 1.2, but is offering TLS 1.0 and 1.1 and I think this is what Google is complaining about. Ideally if you could submit a ticket on this I'd be happy to dig into it for you!

Hey Scott. I'm very familiar with LetsEncrypt and SmarterMail. If you would like to shoot me an email directly, I will see what I can do to help you and then post the answer here if successful :)

Hi Kyle! Not trying to step on toes. Just trying to lend a hand if I can :) I have many deployments of SM and LE and have had a few issues which I was able to successfully solve.

Thanks!

You're good Linda! I appreciate the help :-)

Hi Linda and Kyle,

I have exactly the same issue, I used IISCrypto to ensure that my server does not support TLS 1.0 and 1.1 but I still have the issue with the wrong version number for SSL support.

Any help for this one ?

Best regards,

Eric

Hello Eric! You may want to check what versions are selected in SmarterMail as well, as the system defaults can be overridden in Settings>Protocols>Security Protocols:

I'd be happy to Ron! TLS 1.0/1.1 and ALL versions of SSL are not recommended due to various exploits and overflows available for them and so what I typically recommend is setting SmarterMail to Use System Defaults, downloading and installing IISCrypto (this just makes the changes easier from an admin perspective) and then hitting the Best Practices button once inside of there. You'll notice this leaves TLS 1.0/1.1 enabled for compatibility's sake, so you can uncheck those on the client/server side before applying the changes and rebooting. 

You will want to ensure your end users are running on somewhat recent hardware/software before making that change though, as some older (OLD) versions of Windows/Android OS/iOS don't support newer versions of TLS. A great way to quickly and easily double-check your versions is running an SSL test here:

Make sure you select the Do not show results on the boards checkbox before running those if you don't want your results displayed publicly, but once you run it you'll see a report showing detailed information on what versions and suite versions your server supports. I hope that helps!

Thankfully after upgrading to the latest version of Windows Server I haven't had any of these issues since and now have TLS 1.3, if that helps.

That's great to hear Scott! That should set you up for better overall security too!

On my side here are the settings on my server:

The OS version is Windows Server 2016 Datacenter

On Smartermail, the settings are exactly similar to the one of the screenshot of Kyle

Here is the error message I get when I send message from Gmail:

This issue is really bothering me since months now and I cannot find any solution so any help is appreciated

Here is the result:

seconds
test stage and result[000.000]
Trying TLS on mail.mydomain.com[99.99.99.99:25] (0)[000.099]
Server answered[000.206]<‑‑ 220 mail.mydomain.com[000.207]
We are allowed to connect[000.207]‑‑>EHLO www11-do.CheckTLS.com[000.310]<‑‑ 250-mail.mydomain.com Hello [99.99.99.99]
250-SIZE
250-AUTH LOGIN CRAM-MD5
250-STARTTLS
250-8BITMIME
250-DSN
250 OK[000.311]
We can use this server[000.311]
TLS is an option on this server[000.311]‑‑>STARTTLS[000.410]<‑‑ 220 Start TLS negotiation[000.411]
STARTTLS command works on this server[001.531]
Cannot convert to SSL (reason: SSL connect attempt failed error:1408F10B:SSL routines:ssl3_get_record:wrong version number)[001.532]
Note: This same test with Format set to "Debug" may show more[001.532]‑‑>MAIL FROM:<test@checktls.com>[001.532]<‑‑ ecurity failure[001.532]
Cannot proof email address (reason: MAIL FROM rejected)[001.533]
Note: This does not affect the CheckTLS Confidence Factor[001.533]‑‑>QUIT[001.533]
Read failed (reason: did not read)

If I switch to debug I got the same detail as before:

Setup like this and forget about ssl2 and ssl3 because of insecure (noodle, poodle, goldendoodle attacks). you have to reboot the server.