However, I’m facing an issue where external DANE validators report the following error:
"The DANE TLSA records of these MX hosts fail to validate their certificate chains. Inbound email may be delayed or not delivered."
Upon further inspection, I noticed that when connecting to port 25 (SMTP), the certificate served by Postfix presents mydomain.com as the Common Name (CN), even though mail.mydomain.com is listed as a Subject Alternative Name (SAN) in the certificate.
It appears that the DANE TLSA check is failing due to a mismatch between the MX hostname (mail.mydomain.com) and the CN reported in the certificate, even though the SAN includes it.
My Questions:
Is it mandatory for the certificate’s CN to exactly match the MX hostname (mail.mydomain.com) for DANE to validate correctly, even if it’s listed in the SAN?
Is there a way to configure Postfix (or Virtualmin) to explicitly serve mail.mydomain.com as the CN during the TLS handshake?
Has anyone resolved a similar DANE validation issue in a Virtualmin setup with Let’s Encrypt certificates?
Appreciate any insights or guidance on resolving this issue. Thank you!
Yes. You can configure Virtualmin to explicitly serve the SSL certificate for the mail subdomain by explicitly getting Let’s Encrypt to explicitly give you only that certificate for the virtual server.
Don’t ask Let’s Encrypt to give you a multi-domain certificate but request a single domain one - for your mail subdomain only. Will this cause the website on your domain to lose its SSL certificate? Yes, it will.
To address the TLSA validation issue, I’m considering creating a separate Virtualmin virtual server for mail.mydomain.com, solely to obtain a dedicated Let’s Encrypt SSL certificate for the mail subdomain. The plan is to then use this certificate to configure Postfix.
Would this approach work as intended for DANE/TLSA validation without affecting the existing website SSL setup?
