Email provider not configuring certificate correctly?

Help
1

I'm not sure who else to try and contact about this. I have a hosting provider (xilo) that gives email and web hosting and we tried to register for conferma which is a service for securely transmitting sensitive data over email like banking information etc for businesses. They checked the ssl security and certificates of the email server when we registered (or tried to) and it fails. We ran the email address against checktls.com and it failed on that stating:

Cert Hostname DOES NOT VERIFY (mxs1.xilo.net != mxs1.xscanner.net | DNS:mxs1.xscanner.net)
So email is encrypted but the host is not verified

Further into the log of the tests it mentioned Lets Encrypt as the Issuer/Organisation name.

I have reported this issue to Xilo (the host) twice and they refuse to help and insist everything is ok but it clearly isn't and is stopping us from using their e-mail with conferma.

Is there anyone I can report this to so that it can get sorted out or do I have to accept that Xilo don't want to bother fixing it? Are they not obliged to ensure their certificates are setup correctly or can they get away with leaving these kinds of errors and providing a public service?

Any advice appreciated.
James.

2

I can confirm that the mail setup of xilo is not ideal:

Their mail servers are:

dig MX xilo.net +short
0 mx3.xilo.net.
0 mx4.xilo.net.
0 mx1.xilo.net.
0 mx2.xilo.net.

Connecting to these mailservers (I tested mx1.xilo.net) yields.

# openssl s_client -connect mx1.xilo.net:25 -starttls smtp -verify_hostname mx1.xilo.net
CONNECTED(00000003)
depth=0 CN = mxs1.xscanner.net
verify error:num=62:hostname mismatch
verify return:1
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = mxs1.xscanner.net
verify return:1
---

Indeed, the certificate is only valid for mxs1.xscanner.net, but not the MX record's FQDN itself.

In addition, I had a quick look at the IP's reverse DNS, which is also not ideal for mail (a properly configured mailserver should have fully validating reverse DNS, that is RDNS points back to the MX FQDN):

# dig -x 31.12.127.2 +short
mxs1.xilo.net.

which looks like it's a mix of the first two domains, funny.

Such misconfigurations are unfortunately very common in the email world. Their config is certainly not following industry best practice, but that's the case for many providers out there. Having a mismatching certificate is typically not a big problem, because email uses opportunistic TLS by default. That means certificate errors are just ignored if no other policy (DANE, MTA-STS) is given.

Therefore, most outgoing mail providers will just ignore the invalid certificate and don't care - that's the state of email security. Apparently conferma has different opinions on this though (being banking-related, they may have different policies to follow as well).

There are very few hard requirements on email standards (especially security-related ones) and so there's not much you can do really. There's also nothing Let's Encrypt can do for you. There is no rule preventing someone from using an invalid certificate if they want to.

The best advise we can give is to vote with your wallet and stay away from providers not following best practices.

If I were to speak to xilo, I would ask them why they're so determined on using this weird configuration. They are using multiple certificates each valid for mxs*.xscanner.net. They also announce this FQDN in the SMTP HELO (good!), so why not just use that FQDN as RDNS + MX record? It sounds so easy to do, but whatever :man_shrugging:.

6 Likes
3

Thanks for the fast and very helpful responses. I will be directing Xilo to this thread and hope they eventually do the right thing.

2 Likes
4

That's indeed very common. It's fine to have an MX record with a value totally different than the domain of the DNS zone.

Some mail servers also have SNI support, but as mail clients and (other) mail servers alike often are lacking support for modern things, that wouldn't be a guarantee for success.. I wouldn't count on SNI to be honest.

4 Likes
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.