We don't as the current release seems to have broken or changed this functionality causing high levels of bounces for valid certificates.

I have the setting off for now.

In my case, it rejected a wildcard cert that should have matched the expected. I reported it via a ticket.

13:12:39.919 [21594005] WARNING: Certificate name mismatch. Expected Hostname: mx.mich.com.cust.b.hostedemail.com, Certificate Information: Subject=CN=*.b.hostedemail.com, O=Tucows Inc, L=Toronto, S=Ontario, C=CA Issuer=CN=GeoTrust TLS RSA CA G1, OU=www.digicert.com, O=DigiCert Inc, C=US

My 2c:

Have had to turn OFF "Enforce strict certificate validation".

After a recent upgrade this started happening with outgoing mail to MXs with invalid certs. Either name mismatch or in other cases cert has expired. In one instance, a large NZ ISP was still presenting a cert that had expired over 3 years ago.

My guess is that third party mail servers that use self-signed certs will also fail because they're not signed by a trusted CA.

Additionally, a lot of SMTP 602 bounce messages are generated by SM.

Contrary to other forums posts, there's nothing in the logs about the failures. Although this may be because I've got default logging settings so details aren't being logged.

I have never understood how strict certificate enforcement can be useful for email.   The alternatives are pretty limited:

The first options seems unacceptable and the second option is counterproductive.   In parallel, the likelihood of malicious traffic redirection is much lower than the likelihood of a self-signed or expired certificate.

DNS SEC is a related defense with the same problem.  It blocks DNS lookups that fail signature checks, to prevent malicious redirection caused by DNS poisoning.   Our web filter enforces DNS SEC by default.  The only time that it has detected a problem, it prevented us from getting to the U.S. Center for Disease Control (CDC) website.   It took the government more than  a month to get their problem solved, and we were not willing to be cut off from that information source, so we bypassed DNS SEC enforcement for them.  We have yet to see a DNS SEC event that exposed DNS poisoning.

@Douglas Foster: Your critique pretty much makes the case.  Ostensibly, enabling strict validation ensures you are connecting to the machine to which you expect to connect.

I run my own CA, and certificates for my root and intermediates are installed on all of my machines.  These certs are not publicly facing or for public usage, yet, but when they are they will be for limited use and the necessary certs will be made available.  I recommend anyone using self-signed certificates on publicly-exposed services to make those certificates available for installation as trusted certificates.  Otherwise, Let's Encrypt has made the necessity of using self-signed certificates nearly obsolete.

Of course, the other side of that is Let's Encrypt seems to have also made it easier to obtain fraudulent certificates.  I have been able to use Let's Encrypt to generate certs for my hosted domains without any of the normal validations.  I need to understand more about how this issuance works before I am settled on this aspect.

DNSSEC gets into other territory, and while I understand your position on the need of access, I am generally not willing to bypass someone's misconfiguration or ineptness.  I have dealt with a lot of places with bad configs, be it SPF, DNS in general, or other security measure.  It does become frustrating and extremely difficult to be in the right of "this is their fault, my servers are just doing what they are told to do by them," which is why I welcome more of the juggernauts enforcing standards.  Customers will argue with me as their provider, bad admins will argue with and blame me, but they cannot argue with Microsoft, ComCast, Gmail, &c.

We have accepted that the mail servers across the Internet are SLOPPY and have turned this setting OFF.

+1.  I had to turn mine off too.

It is a shame, and frustrating, that inept administrators are forcing the rest of the Internet so reduce security.  Not at all neighborly. /rant

Seems like mail servers across the world only get secured when Microsoft, Google, or Apple demand it.

I would like to see if there is an ability to turn Dmarc checks on or off per domain. We only use relaxed in our Dmarc records. 

We've left ours on strict, i've been sending courtesy emails to those i notice with expired certs, some are thankful, some action it, some ignore it .. i agree that we have to maintain our certs so why shouldnt others?

We have not and will not turn this off.

We explain to our clients that the destination server is not properly maintained or mis-configured regarding the SSL/TLS encryption certificates. We advise the delivery will continue to fail until the destination server can properly identify itself with verifiable certificates. We advise that this simply protects the mail in transit from MITM attacks and that it will be delivered to it's verifiable intended destination.

We have yet to receive an argument to that reasoning.

We also notify server providers if their certs throw errors for more than 24 hours.

heres a days worth .. if yr cert expired in 2021 yr not really trying are you..

With security being priority one for all of us its really not good enough is it!

[2024.03.20] 13:45:16.494 [71364946] Certificate is expired as of 25/05/2023 5:18:27 PM. 

[2024.03.20] 13:45:36.618 [71364946] Certificate is expired as of 30/05/2023 12:38:49 PM.  

[2024.03.20] 15:05:51.358 [71369219] Certificate is expired as of 8/09/2023 11:33:36 AM. 

[2024.03.20] 16:15:13.910 [71380618] Certificate is expired as of 9/03/2022 3:50:45 PM. 

[2024.03.20] 19:14:49.195 [71385604] Certificate is expired as of 12/03/2024 10:16:44 PM. 

[2024.03.20] 19:16:43.484 [71385644] Certificate is expired as of 11/03/2024 10:13:57 PM. 

[2024.03.20] 19:29:51.219 [71385604] Certificate is expired as of 12/03/2024 10:16:44 PM. 

[2024.03.21] 09:30:54.358 [71397956] Certificate is expired as of 13/11/2021 10:59:59 AM. 

[2024.03.21] 10:00:19.152 [71400397] Certificate is expired as of 22/02/2024 10:13:35 PM. 

[2024.03.21] 10:15:22.921 [71400397] Certificate is expired as of 3/03/2024 10:15:06 PM. 

I agree with @AWRData - We are not turning down or off basic security features because other email administrations are too lazy to fix or just overlooked something.

Most of the time, when we contact an email admin and let them know of an expired cert etc. they are very thankful and get the issue resolved quickly. Just like Mark above, we've seen certs that expired as far back as 2018, which is just insane...

yep lets actively uplift the security of email ourselves, one server at a time!

So what should I tell this administrator is wrong with this certificate?

13:12:39.919 [21594005] WARNING: Certificate name mismatch. Expected Hostname: mx.mich.com.cust.b.hostedemail.com, Certificate Information: Subject=CN=*.b.hostedemail.com, O=Tucows Inc, L=Toronto, S=Ontario, C=CA Issuer=CN=GeoTrust TLS RSA CA G1, OU=www.digicert.com, O=DigiCert Inc, C=US

Fully agree with @Douglas Foster saying "I have never understood how strict certificate enforcement can be useful for email."

We had to turn off strict validation also.  If you're in a high privacy business (medical, legal, finance, etc) that tends to only communicate with similar, then strict validation adds that extra touch of assurance and is a good thing.  For most email, though, every SMB, SOHO, and hobby domain, hosted on "mail.ISP-server.com" will be rejected because the domain of the MX doesn't match the domain of the recipient.  We learned that lesson almost immediately after upgrading.  Complaints of bounced emails started pouring in the first few hours of Monday morning after the upgrade, and we went into panic mode thinking maybe the upgrade was botched.  But it only took a few minutes looking at the logs to realize the root cause was strict validation.

I don't believe the recipient's domain has any impact. The certificate has to match the FQDN of the mail server.

@Patrick Jeski, that could be true, and if so, I'll stand corrected. I'm not the admin who reviewed the logs so I'm just repeating my understanding of what was told to me.  What became clear very quickly, was how many mail servers are sloppy with their certificates.  I also remember the admin working the case mentioning even wildcard certificates were being rejected, that should otherwise have passed.

 

@Patrick Jeski:  They should contact their certificate provider.  Not all wildcard certificates will secure multiple levels of sub-domains.  There are a number of certificate providers offering such certificates, of course for more expense.  One in particular is DigiCert, their existing certificate provider.  Sadly, DigiCert's site is garbage, more of a web-based marketing pamphlet than actually helpful, but it appears its "Wildcard Pro" certificate is the one for this use case.

When you look at Microsoft 365 hosting, you see a wild array of wildcard SANs in its MX certificate.  Of note is the *.mail.protection.microsoft.com.  Rather than having dotted subdomains below this level, it uses the construct of "domain-tld.mail.protection.microsoft.com".  This might be a better way to deal with hosted domains.

BTW - the web site certificate for the hosted domain in question expired on 2/15/2024.  Infer from that what you will.

@AWRData, what a fun rabbit hole you sent me down. 

First, the cert expires Jul 19 23:59:59 2024 GMT according to checkTLS.com 

They also fail the cert for the wildcard. and refer to RFC 2818:

   Matching is performed using the matching rules specified by
   [RFC2459].  If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name, a match in any one
   of the set is considered acceptable.) Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

So the wildcard should not match, and this check should fail. Not a problem for SmarterMail.

Edit to add: Though RFC 2818 is "HTTP Over TLS", so not sure how it applies to mx.

@Patrick Jeski: I meant the mich.com website.  You can assume the TLS certificate rules for HTTP translate to other services, as well.

Where do you turn off  "Enforce strict certificate validation". In the latest version.  I have over 500 emails coming from my clients going out that will not deliver because of the *wildcard mismatch issue.  Clients are getting upset that their mail is not being delivered. I do get the issue of security but this is getting to be a problem real fast.

@Barbara Renowden: Settings/Protocols/SMTP Out

Seems to me that Smartertools may be implementing support for MTA-STS soon with this feature. It is just not perfected yet. 

upgraded to 8860 overnight and so far seems ok, 

However now getting the wildcard certificate mismatch issues which cause 602 errors, i wasnt getting them on build 5768 only the expired certificates errors .. looks like i'll have to turn off the "enforce strict cert validation" checks unfortunately .. disappointing as expired certs should be penalised.

Certificate validation without MTA-STS is futile as too many servers have incorrect config. At least if someone goes to the trouble of configuring MTA-STS they should be configuring certs correctly.

Perhaps have the option of 'enforce strict cert validation' per sending domain? If a client really wants to validate or toggle they can. (Unless the option is there and I have missed it).

I confirm that I also had to deactivate enforce strict cert validation

Many messages remained in the delivery queue

Investigating the problem is precisely that of WARNING: Certificate name mismatch

These are not isolated cases.

For example, it impacts one of the largest Italian providers

Aruba which has the wildcard certificate on its mailservers

Then I would like to point out that even in the log the reporting leads astray

Here's an example

WARNING: Certificate name mismatch. Expected Hostname: mx.associazioneculturaledemos.it, Certificate Information: Subject=CN=mx.aruba.it, O=Aruba S.p.A., L=Ponte San Pietro, S=Bergamo, C=IT Issuer=CN=Actalis Organization Validated Server CA G3 , O=Actalis S.p.A., L=Ponte San Pietro, S=Bergamo, C=IT

This is all resolved by disabling enforce strict cert validation

It's worth investigating on SM's part

We upgraded last night also same issue as Mark.

Once again,

Is not an invalid rejection, but is a misconfiguration by a company which should absolutely know better.

Not sure what SmarterTools should investigate, here.  I would wager that if SmarterMail is refusing to deliver based on the certificate mismatch, services like GMail are going to do the same.

Everybody would be.... its unsecure or misconfigured.

Either way its not a smartermail problem.

Completely mismatched or expired certificates are one issue. Wildcards being limited to one subdomain level is somewhat internet pedantry. I’m guessing by what we are seeing with this issue is that most people think *.mydomain.com is a wildcard for anything that comes before, as I did before this issue came up, and as it realistically should be. 

I think an option for relaxed wildcard matching, as well as strict, would help. The situation I posted near top of this thread would be solved by that, and from what I see it’s typical.