Why you may be better not use Sophos Email solution as of now

We did move away from Sophos Email and here is why we decided to do so.
TLS is a fundamental requirement not just for Websites (HTTPS)  but also for mail exchange and enforced by Central Email. If your company relays on information security certification as ISO27001 or SOC2 or requirements by law (KRITIS) you may have several requirements to not just use techniques like TLS, but also verify their functionality. That includes to check certificates used for communication e.g. do they have a valid chain of trust, are they not rejected or check if they are intended for that target (domain name match).

Sophos Email and SFOS (firewall) checks T LS-certificates by default not just for HTTPS but also for other TLS connection (SMTP). We thought that would meet our requirements as mentioned before. Soon we noticed the certificate check for SMTP does not work as expected. Several domains could not be reached because certificate validation does fail. Quickly it turns out it fails because Sophos certificate check does not work as it should.

What is really annoying, after several month of trying to explain the certificate check does not fail because of incorrect remote hosts configuration, but incorrect certificate check from Sophos involving GES, engineering and product management, Sophos confirmed the issue. However, they also mentioned to have no plans to fix BUG but maybe concluded it as a feature request with no plan to work this for now.

Technical details and what domains are affected:

Sophos checks certificates on SMTP like this example (mail@domain.tld):

1. checks mx-record for domain.tld, let’s assume MX is smtp.domain.tld
2. resolves IP for smtp.domain.tld, let’s assume it is 0.0.0.0
3. connects to IP 0.0.0.0 and checks if certificate cn contains domain.tld.

This works for IP’s only serving one domain (certificate) and do not use SNI (see RFC8446, RFC6066).

The issue:

TLS-vhosts usually running multiple domains on a single IP. If you connect to IP,  no SNI is provided and remote server uses default certificate. That would most likely differ from certificate server would provide using FQDN / SNI and certificate check fails for good reason.

How certificate should work:

1. checks mx-record for domain.tld. Let’s assume MX is smtp.domain.tld
2. connects to FQDN smtp.domain.tld and checks if provided certificate is valid for smtp.domain.tld.

As many freelancer, smaller or midsize companies do use web and mail server with TLS-vhosts support of SNI is fundamental functionality in 2024!

For Central Email we did not find how to disable those checks what means we could not send mails to affected domains.
For Sophos Firewall you can disable certificate check globally (allow invalid certificates) but with that you may not meet legal or certification requirements anymore. (Beside we do not want to pay for Email Protection but then disable significant parts!)