I recently started having *ALL* TLS sessions in SM failing (shortly after adding Security Certs for a couple dozen domains) but a simple reboot of the server thankfully resolved it.

Your situation on the other hand sounds like it is due to the connecting server either not supporting the same protocols or not having a cipher suite in common. We still have some of our SM Servers running on Win2K8R2 and this is becoming more frequent of an issue as TLS_ECDHE_ECDSA_WITH_AES_XXX_GCM_SHAXXX and TLS_ECDHE_ECDSA_WITH_AES_XXX_CBC_SHAXXX are the best cipher suites available on that version of Windows Server and are not universally common as everyone else seems to have moved on to CHACHA_POLY which Microsoft still isn't even supporting even in Win2K18.

Considering how outdated some Mail Servers are (Cable & Telco ISPs are the absolute worst...they set them up in a closet and don't touch them again for two decades it seems) we still keep some pretty old Protocols, Hashes, Key Exchanges, and Cipher Suites enabled on our Incoming and Outgoing Gateways as an insecure TLS 1.0 or SSL 3.0 connection is still better than no secure connection at all. Unless you need HIPPA compliance (or are running SM on Web Servers that need to be PCI-DSS compliant) sometimes purposely playing loose with "Best Practices" is better than missing connections on mail delivery IMHO.

So let me throw a wrench into this...  I thought it might have been due to our Comodo wildcard because I replaced that with a GeoTrust cert specifically for the machine name and all was well.  I tried to switch it back to a Comodo cert specifically for the machine name and then we started getting failures again.  We have a discussion with somebody who is smarter than I am on the cert issues and they mentioned:

    I looked in a bit more detail at the Comodo certificates, and saw that they use MD5/SHA1 combination.  I     suspect this is the problem.  While most implementations do allow TLS 1.2 with MD5/SHA1 for backward     compatibility, stricter ones don’t.

 

What do you guys think about that?

Hoping can get a SM Admin in on this thread. Seems to be a real problem.

Yes, this started to come up more frequently now - we are having big issues with email delivery from Steam specifically with this error.

We were having the same issue as all of you, mostly with AppRiver (“Exception negotiating TLS session…”).  For us it started early in the morning hours of 4/21.  We have several clients that work with some companies that host with AppRiver.  We never had any issues until 4/21.  One of the bigger companies contacted AppRiver and after several days of tickets, AppRiver went in and fixed the issue for that one company but we still had other emails coming in from them that were failing.

 

Our setup is W2012R2 Servers using Comodo Wildcard certificates.  Last night I decided to roll out Let’s Encrypt using Certify SSL Manager (something I was planning on anyway).  Immediately after installing the certificate and exporting it for SmarterMail, the errors stopped and emails came through from AppRiver.

For us this appears to have fixed the issue.  As of this morning, we still have no TLS errors from AppRiver or anyone else.  Going forward now, our setup is to let the Certify software continually update the Let’s Encrypt certificate and I have a PowerShell script automatically export it to SmarterMail every night.

 

Maybe this will help others.  For us, changing the certificate from Comodo immediately fixed the issue, but for sure, AppRiver made some sort of change on their end around 4/21 that started these TLS errors.

Confirmed: Comodo Wildcard SSL certificates is not accepted by AppRiver.

 

Solution: Replace Comodo Wildcard SSL certificate with LetsEncrypt Multi SAN and issues with AppRiver are resolved.

 

Quick workaround: If you configure your SMTP server not to accept TLS 1.2, emails from AppRiver succeed using TLS 1.1.

 

Please note, that this solution only addresses emails sent by AppRiver users to those email addresses you control. AppRiver users may continue to encounter issues sending emails to others.

Greetings,

 

I wanted to add onto what the other community members have stated and to offer a bit of clarification to how SmarterMail negotiates secure connections:

 

The SSPI exceptions are caused by SmarterMail interacting with Microsoft .NET to initiate the secure connection. .NET makes a call to SCHANNEL within Windows to handle the connection negotiation. When the SSPI Exception is encountered, you can review the Windows Event viewer, specifically under the System section for the SCHANNEL errors that took place. You should receive an alert code that you can then compare against the following table from Microsoft to determine the exact error that took place when trying to negotiate the connection: https://msdn.microsoft.com/en-us/library/windows/desktop/dd721886(v=vs.85).aspx

So just to add to this thread, my server started experiencing this issue as well after I applied patch 15.7.6669. I found that I have the same entries in my log file as stated above.

 

[2018.04.22] 16:40:06 [XX.XX.XX][26027413] rsp: 220 XX.XX.XX Sun, 22 Apr 2018 20:40:06 +0000 UTC | SmarterMail Enterprise 15.7.6669
[2018.04.22] 16:40:06 [XX.XX.XX][26027413] connected at 4/22/2018 4:40:06 PM
[2018.04.22] 16:40:06 [XX.XX.XX][26027413] cmd: EHLO server109.appriver.com
[2018.04.22] 16:40:06 [XX.XX.XX][26027413] rsp: 250-XX.XX.XX Hello [XX.XX.XX]250-SIZE250-AUTH LOGIN CRAM-MD5250-STARTTLS250-8BITMIME250 OK
[2018.04.22] 16:40:06 [XX.XX.XX][26027413] cmd: STARTTLS
[2018.04.22] 16:40:06 [XX.XX.XX][26027413] rsp: 220 Start TLS negotiation
[2018.04.22] 16:40:06 [XX.XX.XX][26027413] rsp: 554 Security failure
[2018.04.22] 16:40:06 [XX.XX.XX][26027413] Exception negotiating TLS session: System.NullReferenceException: Object reference not set to an instance of an object.
[2018.04.22] 16:40:06 [XX.XX.XX][26027413] disconnected at 4/22/2018 4:40:06 PM

 

Any idea why I would be getting the 554 Security Failure? The emails never get delivered here. I checked our Event Viewer in Windows under System and found the SCHANNEL error of 40. SSL3_ALERT_HANDSHAKE_FAILURE - SEC_E_ILLEGAL_MESSAGE 0x80090326

 

We only have TLS 1.0, 1.1 and 1.2 enabled on our server and no SSL at all. Any idea whay all of the suddent this started cropping up?

Hi Von,

Thank you for the post here. I already have a SSL certificate through Comodo that is good until 2019. I am getting emails from other providers just fine, IE: Google, Yahoo, AOL, etc. I tried the test you specified above from my machine and I get a 250 OK message. So I really just think this issue has to do with AppRiver specifically.

 

On a side note, when SM writes the header information, is there a setting for it to write in the header what Cipher is being used? Reason I ask is because on our header info I see different information than what Gmail shows on their header info. I will show an example below:

 

SM Header:

Received: from em-sj-47.mktomail.com (em-sj-47.mktomail.com [XX.XX.XX.XX]) by XX.XX.XX.XX with SMTP
	(version=TLS\Tls12
	cipher=Aes256 bits=256);

The best I can recommend on these issues is to run IIS Crypto from Nartac, apply best practices, and monitor for one off failures. In most cases the failures will be mail servers NOT running best practice standards and these can be handled by a backup MX server you leave configured with a lower priority, and more open requirements as far as TLS/SSL goes. Virus and spam scan on this server as well so that by the time it gets passed back to your primary mail server it should be clean and good to go. 

Everyone using Comodo certs, we got report today that the issue appears to be resolved. We noticed that starting this morning connections from AppRiver stopped failing.

Yeah I opened a ticket with them about a week ago and it turns out the filtering software they are using Communigate was the culprit. Communigate released a patch out on 4/30/18 for the issue they were having. I'm guessing that Communigate never told their customers about the issue.

 

I worked with AppRiver to test out one server with TLS connections last week and it worked after they updated 1 server. So I am sure it took some time for them to roll out the update to the rest of their servers. As of Thursday 5/10/18 I still saw a few TLS connection errors, but those disappeared sometime on Friday.

You are all quite welcome. Happy to help and glad that I got a tech that went above and beyond to look into the issue. I made sure to send her a thank you email for all her efforts.