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.

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:

 

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

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]

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. 

I face this issue today.  Kind of disappointing that there is no follow-up for almost 5 years now.

Same

Hello David,

What version of Smartermail and which server OS are you seeing this issue on? 

Best regards,

Maybe this is the issue?

If so, there's a new feature to address it. Turn on "Relaxed certificate name validation" which was recently added/fixed in Build 8972 (Jul 25, 2024).

Good call Kevin, I do think "Enforce Strict Certificate Validation" is what's causing the rejection here. 

However I'm not sure the "Relaxed validation" setting will help in this scenario because that will only ignore certificate naming issues as long as the root top level domain is on the certificate.

Thanks mate, that helped a lot and fixed the issue by Turing on the Relaxed Certificate Name Validation. 

Hello,

That's great to hear. Way to go Kevin!