SMTP TLS Connections Failing

Problem reported by Ryan Wittenauer - April 25, 2018 at 6:41 AM

Not A Problem

Hello,

We have a couple reports of users failing to receive messages from another email provider 'AppRiver'.

In both cases we are receiving failures in our SMTP logs like this:

[2018.04.24] 12:40:38 [8.31.233.131][61550835] disconnected at 4/24/2018 12:40:38 PM
[2018.04.24] 12:41:59 [8.31.233.157][40310597] rsp: 220 email.idmi.net
[2018.04.24] 12:41:59 [8.31.233.157][40310597] connected at 4/24/2018 12:41:59 PM
[2018.04.24] 12:41:59 [8.31.233.157][40310597] cmd: EHLO server83.appriver.com
[2018.04.24] 12:41:59 [8.31.233.157][40310597] rsp: 250-email.idmi.net Hello [8.31.233.157]250-SIZE 31457280250-AUTH LOGIN CRAM-MD5250-STARTTLS250-VRFY250-8BITMIME250 OK
[2018.04.24] 12:41:59 [8.31.233.157][40310597] cmd: STARTTLS
[2018.04.24] 12:41:59 [8.31.233.157][40310597] rsp: 220 Start TLS negotiation
[2018.04.24] 12:41:59 [8.31.233.157][40310597] rsp: 554 Security failure
[2018.04.24] 12:41:59 [8.31.233.157][40310597] Exception negotiating TLS session: The secure connection has failed due to an unsupported protocol such as TLS 1.0 or SSL 3.0. A call to SSPI failed, see inner exception..

We accept TLS 1.0 up to 1.2 connections, but they let us know that they are failing when seeing that accept traffic over TLS 1.0.

Anyone else seeing this happening?

58 Replies

Reply to Thread

Eric Tykwinski Replied

April 25, 2018 at 11:55 AM

I'm seeing the same thing on both SmarterMail v15 and an Exchange 2013 server I run. Both have SSLv3 disable per security standards, so I'm guessing that on outbound they are not supporting TLS1, 1.1, or 1.2. It could be a cipher issue, but I'm still waiting for the customer to have them call us.

Scarab Replied

April 25, 2018 at 1:00 PM

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.

Eric Tykwinski Replied

April 25, 2018 at 1:12 PM

I'm thinking this is a misconfiguration on AppRiver. Looking at a wireshark, they are only negotiating at SSLv3, which is by default turned off on most servers. At least I know Postfix has smtpd_tls_protocols = !SSLv2,!SSLv3 by default, and I believe sendmail is the same.

Just did a wireshark on my servers to figure out what is going on...

Ryan Wittenauer Replied

April 27, 2018 at 9:35 AM

Eric,

Any update? We have tickets open with ST and another vendor we are having nearly the same problem with and both are connected to AppRiver.

Eric Tykwinski Replied

April 27, 2018 at 9:49 AM

Sadly, I believe they just put in a fix for the one client of thiers that was complaining, but all other mail is still failing.
[2018.04.27] 08:10:44 [8.19.118.55][2196227] rsp: 220 smartermail.domain.com
[2018.04.27] 08:10:44 [8.19.118.55][2196227] connected at 4/27/2018 8:10:44 AM
[2018.04.27] 08:10:44 [8.19.118.55][2196227] cmd: EHLO server505.appriver.com
[2018.04.27] 08:10:44 [8.19.118.55][2196227] rsp: 250-smartermail.domain.com Hello [8.19.118.55]250-SIZE 104857600250-AUTH LOGIN CRAM-MD5250-STARTTLS250-8BITMIME250 OK
[2018.04.27] 08:10:44 [8.19.118.55][2196227] cmd: STARTTLS
[2018.04.27] 08:10:44 [8.19.118.55][2196227] rsp: 220 Start TLS negotiation
[2018.04.27] 08:10:45 [8.19.118.55][2196227] cmd: EHLO server505.appriver.com
[2018.04.27] 08:10:45 [8.19.118.55][2196227] rsp: 250-smartermail.domain.com Hello [8.19.118.55]250-SIZE 104857600250-AUTH LOGIN CRAM-MD5250-8BITMIME250 OK

Works fine, but everything else still has 554 Security failure.

I'm sure this is a cipher issue, but I couldn't get anything to add to SmarterMail or my personal Exchange server from them on the phone.

David Short Replied

April 27, 2018 at 11:29 AM

Wow, exact same problem here, same appriver emails. I'll stay tuned. Thanks guys!

Ryan Wittenauer Replied

April 27, 2018 at 1:09 PM

Anyone having an issue with AppRiver.com, are you using a Comodo certificate on your server?

David Short Replied

April 27, 2018 at 1:23 PM

Yes, ours is Comodo issued.

Eric Tykwinski Replied

April 27, 2018 at 1:27 PM

Both of my servers are Comodo as well, but that would be strange... As far as I know most servers don't check validity unless your using DANE. Which I have a server (Linux) using Comodo and DANE, and another server (SmarterMail 17) using Let's Encrypt if you can test it out.

Ryan Wittenauer Replied

April 27, 2018 at 1:54 PM

Yeah, we use separate gateway for certain users and it does not run SM. Our SM gateway and other gateway are both failing AppRiver connections. Both are using a Comodo certificate.

Eric Tykwinski Replied

April 27, 2018 at 5:16 PM

I just dropped an email to MailOps, so hopefully someone from their support team in engineering will contact back with more info. I wish I could test more with clients, but with them putting band-aids in it limits my ability to figure out what the actual problem is. If I hear anything back, I'll post to the list with a RFO.

Eric Tykwinski Replied

April 30, 2018 at 6:20 PM

Well, I've got a trouble ticket in with AppRiver, [129-2279D283-04AC]. They use SmarterTrack, so maybe they at least know of Smartermail :) It's seems like at least I'm getting somewhere, I've sent some NMAP ssl-enum-ciphers scans so they can see at least what we have available. Our operational server just has SSLv3 and RC4 disabled, so it's basically normal operations on most providers and nothing .mil spec. I haven't talked to anyone tier one, but it seems like he's at least relaying messages. If anyone want's to submit another TT, might want to at least mention my ticket number so they can correlate.

J Lee Replied

May 1, 2018 at 8:52 AM

I'm having same issue with one of my clients after migration to SM 16 and Win Server 2016

[2018.05.01] 05:45:21 [32984] CMD: STARTTLS
[2018.05.01] 05:45:21 [32984] RSP: 220 2.0.0 continue
[2018.05.01] 05:45:21 [32984] Exception: A call to SSPI failed, see inner exception.

[2018.05.01]    at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)
[2018.05.01]    at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
[2018.05.01]    at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
[2018.05.01]    at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
[2018.05.01]    at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
[2018.05.01]    at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
[2018.05.01]    at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
[2018.05.01]    at RelayServer.Clients.SMTP.ClientConnectionSync.InitiateSsl(Boolean validateAllCerts)
[2018.05.01]    at RelayServer.Clients.SMTP.SmtpClientSession.#VG(Boolean #5Ni)

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

Anthony DePinto Replied

May 1, 2018 at 9:40 AM

J,

Do you use a Comodo certificate on your server?

J Lee Replied

May 1, 2018 at 10:09 AM

Digicert mail.icfiles.com

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

J Lee Replied

May 1, 2018 at 10:32 AM

I added all the usable 512/521 ciphers to Server 2016 because they do not come with the server by default, this did not fix the issue.

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

Anthony DePinto Replied

May 1, 2018 at 10:59 AM

J, by chance is is a wildcard certificate?

Anthony DePinto Replied

May 1, 2018 at 11:00 AM

Eric and David, are your Comodo certs wildcard certificates?

Eric Tykwinski Replied

May 1, 2018 at 11:14 AM

It has nothing to do with the SSL cert being from Comodo. The issue is that they don't support any of the TLSv1.2 ciphers listed on Microsoft Server 2012 R2 at least on our server. I was able to email back and forth fine with my wildcard and have MTA-STS enabled, so it should have been verifying the certificate. It's a Ubuntu server with Postfix, so has a bit more ciphers available.

Last I heard was that the engineering team was looking into the issue, and possibly adding some of the ciphers we support. Here's our list:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C

Easy to check with Nmap: nmap -sV -p 25 --script ssl-enum-ciphers server.domain.com

J Lee Replied

May 1, 2018 at 11:14 AM

Actually sorry mail.icfiles.com is Digicert RapidSSL and is a Wildcard

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

Anthony DePinto Replied

May 1, 2018 at 12:17 PM

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?

J Lee Replied

May 1, 2018 at 12:22 PM

I changed from Wildcard to mail.icfiles.com cert and same issue

Exception: A call to SSPI failed, see inner exception.

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

Anthony DePinto Replied

May 1, 2018 at 12:32 PM

not sure it was the wildcard anymore, I was leaning towards it being Comodo as that was what all the others on this thread reported, until yours... the first thing I tried was a trial cert from GeoTrust and that's when we saw it started working. I don't know enough to compare the two at that level to see what's the difference.

Anthony DePinto Replied

May 1, 2018 at 1:09 PM

hey J... can you check to see what the intermediate and root certs look like from digicert? Comodo's "do" use SHA-1 in their root/intermediate and I wonder if that's where we're failing. I had a PCI scan fail for this not too long ago but they said we could ignore it so I never thought twice about it.

J Lee Replied

May 1, 2018 at 1:16 PM

Yes I was just thinking the same thing.

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

J Lee Replied

May 1, 2018 at 1:40 PM

Updated the roots for Rapid and Digi and problem seems worse now. I seeing this with a couple of mail services but now noticing all Yahoo.com mail is having this issue.

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

J Lee Replied

May 1, 2018 at 1:43 PM

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

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

Ionel Aurelian Rau Replied

May 2, 2018 at 12:06 AM

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

David Short Replied

May 2, 2018 at 6:43 AM

Yes. Mine is.

Anthony DePinto Replied

May 2, 2018 at 6:56 AM

what I can tell you is, I applied a GeoTrust specific cert to SmarterMail and then a GeoTrust RapidSSL wildcard to another mail platform we run and that seemed to clear the issue up. I'm not sure what J. Lee is running into below, but for us the different certificate provider seems to have cleared most of what we were seeing. We have a thread started with Comodo on this, but who knows if we'll get anywhere.

Anthony DePinto Replied

May 2, 2018 at 6:56 AM

Are you running Comodo certs as well?

Ionel Aurelian Rau Replied

May 2, 2018 at 7:04 AM

Indeed I am

Craig Moench Replied

May 2, 2018 at 7:17 AM

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.

J Lee Replied

May 2, 2018 at 7:38 AM

Do you allow SSL 3.0 or below? Are you planning on turning off TLS 1.0 and 1.1?

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

Craig Moench Replied

May 2, 2018 at 7:49 AM

On both SM servers (running the latest SM v16,) SSLv3 is disabled and has been for a long time. One server has TLS 1.0, 1.1 and 1.2 enabled. On the other server TLS 1.1 and 1.2 are enabled but 1.0 is disabled (for testing). Both are now running Let's Encrypt and I have no TLS errors on either but I will say that there is a lot more traffic on the one that has TLS 1.0 enabled. I am planning on disabling 1.0 on our heavy traffic server over the weekend to test for any errors.

David Barker Replied

May 2, 2018 at 10:24 AM

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.

David Short Replied

May 2, 2018 at 1:45 PM

How do you configure your SM server to not accept TLS 1.2?

Von-Austin See Replied

May 3, 2018 at 7:36 AM

Employee Post

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

Von See
Technical Support Supervisor
SmarterTools Inc.
(877) 357-6278
www.smartertools.com

J Lee Replied

May 3, 2018 at 7:55 AM

I'm running RapidSSL

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

J Lee Replied

May 3, 2018 at 7:56 AM

Yes I'm only seeing this with SM 16, my SM 15 with same RapidSSL cert is running fine

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

Jay Altemoos Replied

May 3, 2018 at 10:30 AM

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?

J Lee Replied

May 3, 2018 at 10:45 AM

I'm running SmarterMail Enterprise Version - 16.3.6684

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

J Lee Replied

May 3, 2018 at 10:47 AM

This gives no usable error code for me.
0x8000000000000000

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

Von-Austin See Replied

May 3, 2018 at 10:50 AM

Employee Post

Jay, the 554 Security failure is being thrown due to the exception being encountered with the SHCANNEL provider within Windows. The client machine is likely encountering an issue during the TLS handshake. You'll want to perform a capture of the network traffic from this source IP to your server.

What you'll be looking for here is if the fails before completion, or after the client\server hello. If the TLS handshake fails after the CLIENT HELLO there's likely an issue on the sending client performing the connection. For this you can test using OpenSSL on the client's machine and seeing if a TLS connection can be established over port 25. The command syntax for this is 'openssl.exe s_client -starttls smtp -crlf -connect host.domain.com:25' if the connection succeeds you're likely looking at a client incompatibility issue.

If the TLS handshake fails after the SERVER HELLO, there's likely an issue with the SSL certificate itself such as an incorrect or missing CA, or an issue negotiating Cipher Suites.

Please note that our Cryptography\SSL implementation has not changed since version 14. Updating to the latest release may have been a coincidence.

To confirm, does the issue persist if you deploy let's encrypt per our blog post here: https://www.smartertools.com/blog/2017/08/14-secure-smartermail-with-lets-encrypt ?

Von See
Technical Support Supervisor
SmarterTools Inc.
(877) 357-6278
www.smartertools.com

Jay Altemoos Replied

May 3, 2018 at 12:57 PM

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);

Gmail Header:

Received: from XX.XX.XX.XX (XX.XX.XX.XX. [XX.XX.XX.XX])
        by mx.google.com with ESMTPS id u17-v6si12911316qvk.226.2018.05.03.12.16.20
        for <XX@XX.com>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);

So as you can see Gmail publishes the specific cipher in the header information, where as when I look at the header in my email on webmail for some reason the header doesn't show as much info for the cipher. Is there a setting for that somewhere? Or is it that AES256 was all that was used.

Von-Austin See Replied

May 3, 2018 at 1:10 PM

Employee Post

Jay, I've submitted a feature request with our SmarterMail development team for the header enhancements for writing the full cipher suite used.

Von See
Technical Support Supervisor
SmarterTools Inc.
(877) 357-6278
www.smartertools.com

Kyle Kerst Replied

May 3, 2018 at 1:30 PM

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.

Kyle Kerst Cameron Solutions LLC www.cameron-solutions.com

David Barker Replied

May 3, 2018 at 1:40 PM

I did all this and more. I had to replace my SSL certificate to resolve the issue with AppRiver. I strongly believe this an AppRiver issue but getting them to fix it has been fruitless. I have spent days and days tracing, testing, emailing, calling, all to no avail. AppRiver simply seems not able to identify the issue they are having communicating with SMTP servers that are using a Comodo SSL Wildcard certificate. I believe the issue has something to do with a security chaining issue at AppRiver. The simplest solution for me was to replace the SSL certificate. I used a free LetEncrypt multi SAN certificate. Problem solved for me. Unfortunately not for everyone else who is having issues getting emails from AppRiver. Like I said, this appears to be a AppRiver issue.

Jay Altemoos Replied

May 3, 2018 at 2:35 PM

Ok Von that sounds great.

John Reid Replied

May 9, 2018 at 4:22 PM

It looks like we are in the same boat. My logs are filled with :

cmd: EHLO server121.appriver.com
rsp: 250-shastaemail.com Hello [8.31.233.133]250-SIZE 52428800250-AUTH LOGIN CRAM-MD5250-STARTTLS250-8BITMIME250 OK
cmd: STARTTLS
rsp: 220 Start TLS negotiation
rsp: 554 Security failure
Exception negotiating TLS session: System.NullReferenceException: Object reference not set to an instance of an object.
disconnected at 5/9/2018 3:40:58 PM

We are using best practices and score an A at SSL Labs server test. Appriver is the only provider I am aware of that we are having issues with. A test E-mail that was CCed to a G-mail account manged to get delivered, and it said the connection was:
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128)

Ryan Wittenauer Replied

May 14, 2018 at 11:00 AM

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.

Jay Altemoos Replied

May 14, 2018 at 11:20 AM

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.

Jane Noel Replied

May 14, 2018 at 11:26 AM

Jay, thanks for the update. I've had a ticket in wtih AppRiver for a week too - but I never got anywhere with them.

Jay Altemoos Replied

May 14, 2018 at 11:28 AM

I told them about this thread and gave them the link here. So their engineering dept. looked this thread over and figured out where the issue was.

J Lee Replied

May 14, 2018 at 12:50 PM

My issue was resolved by enabling these cipher suites, they are disabled by default in Win 2016, which is what we just migrated to when we noticed the problem.

TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) WEAK 256
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) WEAK 128
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) WEAK 256
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) WEAK 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK 128

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

J Lee Replied

May 14, 2018 at 12:52 PM

Nice I see my appriver logs are connecting with no error as well.

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

Ryan Wittenauer Replied

May 14, 2018 at 12:54 PM

Thanks for the information Jay!

Jay Altemoos Replied

May 14, 2018 at 1:10 PM

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.

Back to Community Threads

Please leave this box unchecked

58 Replies

Reply to Thread

Related Community Threads

Related Knowledge Base Articles