I not sure how to fix the certificate exceptions.
Problem reported by Fred Needham - November 26 at 9:33 AM
Resolved
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

3 Replies

Reply to Thread
0
Kyle Kerst Replied
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
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
1
Paul Blank Replied
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.





1
Fred Needham Replied
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).

Reply to Thread