SMTP false positive bug: there is no hostname mismatch here

[HLFH]

H @aeris,

You can see that I have M score on this CryptCheck test. And here, I have a F score on another CryptCheck test based on the same SMTP server. And when I'm using ssl-tools.net service, I have green results with no hostname mismatch. It seems that CryptCheck puts wrongly a M score for acsemb.org because its SMTP server is arch-server.hlfh.space and that the TLS certificate includes *.hlfh.space. So, I don't understand well the M score here. It seems that CryptCheck checks if the SMTP TLS certificate matches the acsemb.org domain, but with drill MX acsemb.org, you understand that for TLS certificates, acsemb.org should not be checked but the MX hostname arch-server.hlfh.space. Am I right?

Thanks

[aeris]

I’m not (totally) agree with ssl-tools result.

I’m not agree because from pure X.509 point of view, certificate for acsemb.org:25 is valid only for CN=.dinepont.fr, DNS:.dinepont.fr, DNS:dinepont.fr, DNS:dhautefeuille.eu, DNS:.dhautefeuille.eu, DNS:gitnote.eu, DNS:.gitnote.eu, DNS:hlfh.space and DNS:*.hlfh.space. So not valid for acsemb.org and the M score but valid for hlfh.space and the F score (which is totally normal for SMTP).

But SMTP is an ugly world, and certificate validation must not be check.

We have the trouble that MX domain can be different from the domain itself (your case), and there is no official statement of what domain you have to choose for certificate validation. From security point of view, you have to check the real domain (MITM detection), but for deployment point of view, you have to check the MX domain (you don’t want to have cert renew each time you host a new domain on a mutualised MTA).

Worst, there is an official RFC 7672 saying you must not expect root CA on the MTA part, and so, no domain verification at all must be done.

In clear, any certificat is valid from a SMTP point of view, even if expired, forged, misused or wrong.

The M scoring on cryptcheck is only because of the generic TLS test used, with no reference to SMTP, and so cryptcheck perform the standard checks.

[HLFH]

@aeris Hi. Thanks for the explanation.

Could we expect next year a better certificate validation with DNSSEC, SMTP STS and DANE/TLSA?

With RainLoop, the SMTP TLS certificate is verified against the MX domain, and if the TLS check is enabled, we can't send emails if the SMTP TLS certificate does not match the MX domain.

So, I finally guess I have to create a Let's Encrypt SMTP TLS certificate with at least all these domains (TLS >> acsemb.org, dhautefeuille.eu, hlfh.space, dinepont.fr, arch-server.hlfh.space) to make it 100% work. For now, I guess I just have to modify the SMTP TLS certificate and that we are not advised to enable these Postfix features: smtp_tls_security_level = dane and smtp_dns_support_level = dnssec because it would enforce too much security:

For purposes of protocol and cipher selection, the "dane" security level is treated like a "mandatory" TLS security level, and weak ciphers and protocols are disabled. Since DANE authenticates server certificates the "aNULL" cipher-suites are transparently excluded at this level, no need to configure this manually. RFC 6698 (DANE) TLS authentication is available with Postfix 2.11 and later.

[HLFH]

@aeris

Solved. I updated the SMTP TLS certificate: it now takes care of the domains + MX domain. And I updated the TLSA RR.