Back to Community Threads
4
I not sure how to fix the certificate exceptions.
Problem reported by Fred Needham - 11/26/2018 at 9:33 AM
Submitted
Smartermail 15.7.6885.  The new certificate messages are nice; however, some are not very clear and I'm not sure how to go about fixing the problems.

The following message is excellent.
[2018.11.25] 17:52:06 [03431] Certificate is expired as of 3/9/2018 5:10:39 PM.
[2018.11.25] 17:52:06 [03431] Exception: The remote certificate is invalid according to the validation 
procedure.

Is the follow message good / bad ? Is it informational only?
[2018.11.25] 01:24:31 [85939] Certificate ChainStatus has returned a non empty array.

The following message could use some improvement.
[2018.11.25] 00:08:45 [85563] Certificate name mismatch.
I am assuming that the reverse DNS lookup does not match the certificate.  I would like to see the message to show:
[2018.11.25] 00:08:45 [85563] Certificate name mismatch. DNS shows mail.example.com. Certificate shows smtp.example.com, pop.example.com ....
If smartermail would show what doesn't match, one would quickly know if the reverse DNS or the certificate is wrong.

Is there any was to fix the following error (I'm using windows 2008r2)?:
07:11:14 [33157] Exception: A call to SSPI failed, see inner exception.
Stack:    at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
   at RelayServer.Clients.SMTP.ClientConnectionSync.InitiateSsl(Boolean validateAllCerts)
   at RelayServer.Clients.SMTP.SmtpClientSession.#VG(Boolean #5Ni)
Inner Exception: The client and server cannot communicate, because they do not possess a common algorithm

Is there any was to fix the following error (I'm using windows 2008r2)?:
09:16:33 [69372] Exception: A call to SSPI failed, see inner exception.
Stack:    at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
   at RelayServer.Clients.SMTP.ClientConnectionSync.InitiateSsl(Boolean validateAllCerts)
   at RelayServer.Clients.SMTP.SmtpClientSession.#VG(Boolean #5Ni)
Inner Exception: The token supplied to the function is invalid

5 Replies

Reply to Thread
1
Kyle Kerst Replied
11/26/2018 at 3:39 PM
Employee Post Marked As Resolution
Hello and good afternoon. I'm sorry you're having this issue on your server. From what I can see in the logs it looks like your server and the sending server do not have a set of SSL/TLS cipher suites in common that can be used to transmit the message. This typically indicates that the sending or receiving server has been configured for higher security requirements than the other. To determine which is the case you can use OpenSSL to interrogate the remote server and determine what suites it has available to it using the instructions found here: https://superuser.com/questions/109213/how-do-i-list-the-ssl-tls-cipher-suites-a-particular-website-offers (adapting the procedure for SMTP port 465.) To resolve the issue I recommend making use of IIS Crypto provided by Nartac Software, as this application includes a "Best Practices" button that will configure your mail server for the highest possible security.
Kyle Kerst System/Network Administrator SmarterTools Inc. (877) 357-6278 www.smartertools.com
1
Paul Blank Replied
11/28/2018 at 7:56 AM
There are various certificate checkers on the Web that you can use. 

Here's one where you can check the individual port #s:


It doesn't say so anywhere on the page, but you can, for instance, enter email.contoso.com:993 and it will check that port. Be patient - takes a bit of time to get the result, but it worked when I double-checked it before posting this.

When adding certificates to SM, I have been instructed to use a cert that is in X.509 format. This works for me.

Here's another site, can use same format to check port #s:


NOTE: there is one SSL checker out there (not either of the above links) that reports that the "Root 1" certificate is missing. This result is either inconsequential or is just plain wrong. My certs check out everywhere else, both in testing and in practice.
3
Fred Needham Replied
12/5/2018 at 8:36 AM
Nice that this got marked resolved, when nothing got resolved.
After chasing certificate problems down for a week or so, I came to the following conclusions:

Please stop validating certificates when sending email to other mail servers.
 
Smartermail’s current philosophy is to not send via TLS to any mail server who’s certificate fails validation (expired, wrong domain, self-signed).
Smartermail needs to change its philosophy to use any certificate send by a mail server to transmit TLS.
 
1. Smartermail will send an email via plain text if TLS fails.
2. The Goal is to send as many emails with TLS as possible.
3. The receiving mail server sends a certificate to Smartermail to use for TLS
4. Smartermail should use that certificate NO MATTER WHAT to send TLS.
 
Who cares if the certificate is expired, for the wrong domain, or self-signed?  Smartermail should use that certificate to send via TLS. If the certificate doesn’t validate, Smartermail turns around and send the email ANYWAY, in PLAIN TEXT, which is the most UNSECURE way to send the email. It doesn’t matter that the certificate could be fake, Smartermail is going to send the email via plain text anyway.
 
I came to this conclusion last night as I was chasing down certificate issues. Use the following website:
Try domains: fortbendcountytx.gov and kohls.com
Here is a major department store and a government agency using self-signed certificates.  How is Smartermail ever going to send to self-signed certificates via TLS if Smartermail doesn’t change their philosophy?
 
I have over 10,000 emails a day that could be send via TLS but aren’t because of Smartermail’s choice to validate the certificate. Please stop validating certificates!

I have opened a ticket on this issue.(16B-23999EDB-003C).
0
David Jamell Replied
6/14/2019 at 6:53 AM
I'm getting one of the same errors on Version 100.0.7093 

I use the Nartec Software to configure all of my servers and have validated the certificate on our server using SSLLabs.

Here is the specfic error:

[2019.06.14] 08:02:03.773 [11289] Certificate ChainStatus has returned a non empty array.

Here is the full transcript:

[2019.06.14] 08:01:56.994 [11289] Delivery started for jana.mundy@gpfsm.com at 8:01:56 AM
[2019.06.14] 08:02:00.040 [11289] Added to SpamCheckQueue (0 queued; 1/50 processing)
[2019.06.14] 08:02:00.040 [11289] [SpamCheckQueue] Begin Processing.
[2019.06.14] 08:02:00.103 [11289] Starting Spam Checks.
[2019.06.14] 08:02:00.103 [11289] Skipping spam checks: User authenticated
[2019.06.14] 08:02:00.103 [11289] Spam Checks completed.
[2019.06.14] 08:02:00.103 [11289] Removed from SpamCheckQueue (0 queued or processing)
[2019.06.14] 08:02:03.050 [11289] Added to RemoteDeliveryQueue (1 queued; 0/50 processing)
[2019.06.14] 08:02:03.050 [11289] [RemoteDeliveryQueue] Begin Processing.
[2019.06.14] 08:02:03.050 [11289] Sending remote mail for jana.mundy@gpfsm.com
[2019.06.14] 08:02:03.113 [11289] MxRecord count: '2' for domain 'kohls.com'
[2019.06.14] 08:02:03.218 [11289] Attempting MxRecord Host Name: 'mx2.kohlsinbound.iphmx.com', preference '1', Ip Count: '12'
[2019.06.14] 08:02:03.218 [11289] Attempting to send to MxRecord 'mx2.kohlsinbound.iphmx.com' ip: '68.232.142.10'
[2019.06.14] 08:02:03.218 [11289] Sending remote mail to: kohlsrcpt@kohls.com
[2019.06.14] 08:02:03.218 [11289] Initiating connection to 68.232.142.10
[2019.06.14] 08:02:03.218 [11289] Connecting to 68.232.142.10:25 (Id: 1)
[2019.06.14] 08:02:03.249 [11289] Connection to 68.232.142.10:25 from 172.107.33.100:56218 succeeded (Id: 1)
[2019.06.14] 08:02:03.506 [11289] RSP: 220 esa7.kohlsinbound.iphmx.com ESMTP
[2019.06.14] 08:02:03.506 [11289] CMD: EHLO mail.gpfsm.com
[2019.06.14] 08:02:03.585 [11289] RSP: 250-esa7.kohlsinbound.iphmx.com
[2019.06.14] 08:02:03.585 [11289] RSP: 250-8BITMIME
[2019.06.14] 08:02:03.585 [11289] RSP: 250-SIZE 26214400
[2019.06.14] 08:02:03.585 [11289] RSP: 250 STARTTLS
[2019.06.14] 08:02:03.585 [11289] CMD: STARTTLS
[2019.06.14] 08:02:03.647 [11289] RSP: 220 Go ahead with TLS
[2019.06.14] 08:02:03.773 [11289] Certificate ChainStatus has returned a non empty array.
[2019.06.14] 08:02:03.788 [11289] CMD: EHLO mail.gpfsm.com
[2019.06.14] 08:02:03.850 [11289] RSP: 250-esa7.kohlsinbound.iphmx.com
[2019.06.14] 08:02:03.850 [11289] RSP: 250-8BITMIME
[2019.06.14] 08:02:03.850 [11289] RSP: 250 SIZE 26214400
[2019.06.14] 08:02:03.850 [11289] CMD: MAIL FROM:<jana.mundy@gpfsm.com> SIZE=2642
[2019.06.14] 08:02:04.177 [11289] RSP: 250 sender <jana.mundy@gpfsm.com> ok
[2019.06.14] 08:02:04.177 [11289] CMD: RCPT TO:<kohlsrcpt@kohls.com>
[2019.06.14] 08:02:04.240 [11289] RSP: 250 recipient <kohlsrcpt@kohls.com> ok
[2019.06.14] 08:02:04.240 [11289] CMD: DATA
[2019.06.14] 08:02:05.472 [11289] RSP: 354 go ahead
[2019.06.14] 08:02:05.661 [11289] RSP: 250 ok:  Message 178393128 accepted
[2019.06.14] 08:02:05.661 [11289] CMD: QUIT
[2019.06.14] 08:02:05.724 [11289] RSP: 221 esa7.kohlsinbound.iphmx.com
[2019.06.14] 08:02:05.724 [11289] Attempt to ip, '68.232.142.10' success: 'True'
[2019.06.14] 08:02:05.739 [11289] Delivery for jana.mundy@gpfsm.com to kohlsrcpt@kohls.com has completed (Delivered)
[2019.06.14] 08:02:05.739 [11289] Removed from RemoteDeliveryQueue (0 queued or processing)
[2019.06.14] 08:02:06.091 [11289] Removing Spool message: Killed: False, Failed: False, Finished: True
[2019.06.14] 08:02:06.091 [11289] Delivery finished for jana.mundy@gpfsm.com at 8:02:06 AM    [id:315611289]
0
Kyle Kerst Replied
6/14/2019 at 9:26 AM
Employee Post
Hello Fred, good morning to you! I apologize for marking this resolved when you feel it was not. The original request detailed SSL certificate related errors, how to resolve them, and what might cause them. 99% of the time these issues arise due to incompatibilities in the cipher suites being used between sending/receiving servers, and so the process I provided is technically the resolution. Now, if this doesn't resolve the issues you're facing I definitely suggest getting a support ticket submitted so we can take a closer look at this for you. For now I have adjusted the thread status to Submitted instead of Resolved.

As to the behavior of sending via plain SMTP when a certificate error is encountered; I'm working on testing this now to get it confirmed, and will relay my findings to development so we can get that squared away soon. If you submit a support ticket on this I can associate it with the bug report and that way we can get you an update as we find out more. 

Lastly, I have asked our development team about the error referenced (non-empty array) and will follow up when I hear back on this. 
Kyle Kerst System/Network Administrator SmarterTools Inc. (877) 357-6278 www.smartertools.com
Back to Community Threads

Reply to Thread

Related Knowledge Base Articles

SmarterTools Licensing InformationGeneral Topics
Set up Autodiscover for SmarterMailSmarterMail > Installation and Configuration
Automatic SSL Certificates on a New SmarterMail ServerSmarterMail > Server Configuration and Management
Troubleshooting SmarterMail Automatic SSL CertificatesSmarterMail > Troubleshooting
Integrating Existing SSL Certificates With SmarterMail Automated SSL CertificatesSmarterMail > Server Configuration and Management