4
Enforce strict certificate validation
Question asked by Ron Raley - 3/14/2024 at 7:31 AM
Unanswered
We have the "Enforce strict certificate validation" checked under SMTP Out.  Now, weekly customers are reporting unable to connect to send mail to various vendors.

[2024.03.13] 11:37:15.277 [70671252] WARNING: Certificate name mismatch. Expected Hostname: mx.centurylink.net, Certificate Information: Subject=CN=*.mx.a.cloudfilter.net, O="Proofpoint, Inc.", S=California, C=US Issuer=CN=Sectigo RSA Organization Validation Secure Server CA, O=Sectigo Limited, L=Salford, S=Greater Manchester, C=GB

MX Record Port 25: mx.centurylink.net
SSL Binding Port 25:*.mx.a.cloudfilter.net

This bounces the message.  Tony advised to keep this setting on and turning it off can present danger.  I'm seeking customer feedback to see if they use this settings or not.

33 Replies

Reply to Thread
3
SmP Replied
We don't as the current release seems to have broken or changed this functionality causing high levels of bounces for valid certificates.
2
Patrick Jeski Replied
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
1
Bert Garrett-Tuck Replied
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.
1
AWRData Replied
MX Record Port 25: mx.centurylink.net
SSL Binding Port 25:*.mx.a.cloudfilter.net

This looks like a proper rejection.  Neither the certificate nor the SAN match the requested hostname.  This is likely a misconfiguration of the recipient domain.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0b:d2:85:6a:6c:ef:0a:df:51:fc:61:82:12:59:5b:76
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Organization Validation Secure Server CA
        Validity
            Not Before: Sep  6 00:00:00 2023 GMT
            Not After : Sep  5 23:59:59 2024 GMT
        Subject: C=US, ST=California, O=Proofpoint, Inc., CN=*.mx.a.cloudfilter.net
...clipped...
            X509v3 Subject Alternative Name:
                DNS:*.mx.a.cloudfilter.net


The nice thing about security lock-downs of major providers, e.g. Google, is mail server and DNS misconfigurations will be forced to be resolved.  I consistently have to deal with "well, it works with x service, the problem must be you" when addressing bad SPF or DMARC records, or improperly configured DNS.
1
Douglas Foster Replied
I have never understood how strict certificate enforcement can be useful for email.   The alternatives are pretty limited:
  • Cut yourself off from being able to send email any organization that uses a self-signed or expired certificates, or
  • Downgrade from "encryption without server identity verification" to "cleartext without server identity verification".
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.

3
AWRData Replied
@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.
5
Ron Raley Replied
We have accepted that the mail servers across the Internet are SLOPPY and have turned this setting OFF.
0
Mike Mulhern Replied
+1.  I had to turn mine off too.
4
AWRData Replied
It is a shame, and frustrating, that inept administrators are forcing the rest of the Internet so reduce security.  Not at all neighborly. /rant
3
Ron Raley Replied
Seems like mail servers across the world only get secured when Microsoft, Google, or Apple demand it.
0
J Lee Replied
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. 
J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273
2
Mark Johnson Replied
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?
2
J. LaDow Replied
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.
MailEnable survivor / convert --
2
Mark Johnson Replied
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. 
3
echoDreamz Replied
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...
2
Mark Johnson Replied
yep lets actively uplift the security of email ourselves, one server at a time!
0
Patrick Jeski Replied
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
0
Jay Dubb Replied
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.
1
Patrick Jeski Replied
I don't believe the recipient's domain has any impact. The certificate has to match the FQDN of the mail server.
0
Jay Dubb Replied
@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.
 
0
AWRData Replied
@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.
3
Patrick Jeski Replied
@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.
0
AWRData Replied
@Patrick Jeski: I meant the mich.com website.  You can assume the TLS certificate rules for HTTP translate to other services, as well.
0
Barbara Renowden Replied
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 President / Co-Founder Centric Web, Inc. https://www.centricweb.com
2
AWRData Replied
@Barbara Renowden: Settings/Protocols/SMTP Out
2
Chris Replied
Seems to me that Smartertools may be implementing support for MTA-STS soon with this feature. It is just not perfected yet. 
0
Mark Johnson Replied
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.

[2024.04.10] 04:47:23.887 [68441984] WARNING: Certificate name mismatch. Expected Hostname: us2.mx3.mailhostbox.com, Certificate Information: Subject=CN=us2.mx.mailhostbox.com Issuer=CN=Sectigo RSA Domain Validation Secure Server CA, O=Sectigo Limited, L=Salford, S=Greater Manchester, C=GB
0
Nathan Replied
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).
2
Sabatino Replied
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
Sabatino Traini Chief Information Officer Genial s.r.l. Martinsicuro - Italy
2
Gary P Replied
We upgraded last night also same issue as Mark.

Messages remained in the delivery queue.
4
AWRData Replied
Once again,
WARNING: Certificate name mismatch. Expected Hostname: mx.associazioneculturaledemos.it, Certificate Information: Subject=CN=mx.aruba.it,
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.
1
Everybody would be.... its unsecure or misconfigured.

Either way its not a smartermail problem.
4
Patrick Jeski Replied
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. 

Someone who holds a certificate for *.b.hostedemail.com is probably not a risk for mx.mich.com.cust.b.hostedemail.com. 

Reply to Thread