Hello Viktor,
[CC'ing dane-users list to mea culpa to the Internet at large, appreciate any advice ;-)]
On Mon, Dec 03 2018, Viktor Dukhovni wrote:
Your TLSA RRset does not match the actual certificate chain of some of your MX hosts. It is better to have no TLSA records than to have incorrect TLSA records. Please adopt a *better* key rotation approach, what you're doing now is fragile and DOES NOT work reliably.
Suggested more robust TLSA record management approaches are described in slides presented at the ICANN61 conference in March of 2018:
http://imrryr.org/~viktor/ICANN61-viktor.pdf http://imrryr.org/~viktor/icann61-viktor.mp3The relevant DNS records are:
; DANE TLSA fail ; None of the TLSA records match the certificate chain ; _25._tcp.azathoth.unzane.com. IN CNAME azathoth-rsa._tlsa.unzane.com. azathoth-rsa._tlsa.unzane.com. IN TLSA 3 1 2 ee8dad1abbb174615af798cf240f044ee176e4a761bd156e2adc2aa496b7a315af1c5b04ff8ba3fe48a4457f87bded23c5d76a3c8743040b9d69ff302046f768Affected domains:
unzane.com. IN MX 10 azathoth.unzane.com.
Thank you for informing me of this misconfiguration at my site.
I'm curious whether your DANE validation scans had found my mail server to validate successfully in the past, prior to Saturday December 1st, 8:20AM PST. Coincidentally this is time that the OpenSSL package within Debian stable/security-updates archive had been upgraded on this server, from version 1.1.0f-3+deb9u2 to version 1.1.0j-1~deb9u1. This upgrade triggered SMTP STARTTLS monitoring alarms (using Monit, checking fingerprints), which I had rectified, however I had neglected the impact to DANE.
For whatever forgotten reason, the x509 certificates for this site are "dual stacked", one set of certificates for RSA, and another set of certificates for ECDSA. Postfix had been configured to support both chains of certificates (smtp_tls_cert_file + smtp_tls_eccert_file). To my surprise, the minor OpenSSL version bump must have changed cipher suite order and caused the ECDSA flavor to be served.
I read your ICANN61 slides (very nice, BTW), and tried the Bash/OpenSSL DANE check function at the end. Appending openssl s_client option "-cipher 'HIGH:-ECDHE'" causes the check to pass. Nevertheless, I've updated our TLSA records to include the ECDSA flavor. Check now passes with or without the explicit cipher suites hack.
Although I missed the opportunity to run your DANE/SMTP web validator¹ prior to updating my TLSA records, FWICT it looks like the web validator is using RSA flavor connections, thus would have passed prior to fixing the TLSA records for ECDSA flavor. Guessing here becuase of the green highlighted row "3, 1, 2 ee8dad1abbb17461[...]9d69ff302046f768" was the RSA record that had existed prior to the fixes.
¹ https://dane.sys4.de/smtp/unzane.com