On 2017-05-18 at 10:51 -0400, Viktor Dukhovni wrote:
If you want to check that your Postfix is doing DANE minimally correctly per this site, just try:
$ myemail=... $ sendmail -bv -f $myemail probe-rcpt@wrong.havedane.net $ sendmail -bv -f $myemail probe-rcpt@do.havedane.net $ sendmail -bv -f $myemail probe-rcpt@dont.havedane.net
Then check your logs. You should see something along the lines of:
I just sent one email to all three addresses using my MUA. Seems easier. ;)
Exim passes; `exim -Mvl` on the message left on the queue because of `wrong.havedane.net` yields:
2017-05-18 22:08:49 Received from [censored] H=(tower.spodhuis.org) [censored]:29796 I=[censored]:587 P=esmtpa A=auth_gssapi:[censored] S=613 id=20170518220848.GA91791@tower.spodhuis.org 2017-05-18 22:08:49 dc6f134be71d9a96@do.havedane.net: remote_dksign transport succeeded 2017-05-18 22:08:49 dc6f134be71d9a96@dont.havedane.net: remote_dksign transport succeeded 2017-05-18 22:08:50 dc6f134be71d9a96@wrong.havedane.net R=outbound_signed T=remote_dksign defer (-37) H=wrong.havedane.net [5.79.70.105]:25: failure while setting up TLS session
The per-message logs are not as helpful to why TLS verification failed, but the mainlog has more details (if configured appropriately with log_selector).
The `DS` field flags DNSSEC secure results, the `CV=dane` is Certificate Verification.
-----------------------------8< mainlog >8------------------------------ 2017-05-18 22:08:49 [91803] 1dBTbE-000Nsg-Vq => dc6f134be71d9a96@do.havedane.net F=<...> P=<...> R=outbound_signed T=remote_dksign H=do.havedane.net DS [2001:1af8:4700:a118:90::7c0]:25 I=[2a02:898:31:0:48:4558:736d:7470]:29798 X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=dane DN="/C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/OU=MyOrganizationalUnit/CN=do.havedane.net/name=EasyRSA/emailAddress=me@myhost.mydomain" C="250 2.0.0 Ok: queued as CF3D2C0CF4" QT=1s DT=0s
2017-05-18 22:08:49 [91803] 1dBTbE-000Nsg-Vq => dc6f134be71d9a96@dont.havedane.net F=<...> P=<...> R=outbound_signed T=remote_dksign H=dont.havedane.net DS [2001:1af8:4700:a118:90::7c0]:25 I=[2a02:898:31:0:48:4558:736d:7470]:29797 X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no DN="/C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/OU=MyOrganizationalUnit/CN=do.havedane.net/name=EasyRSA/emailAddress=me@myhost.mydomain" C="250 2.0.0 Ok: queued as D82F2C0CF5" QT=1s DT=0s
2017-05-18 22:08:49 [91807] 1dBTbE-000Nsg-Vq H=wrong.havedane.net [2001:1af8:4700:a118:90::7c0] TLS error on connection (SSL_connect): error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed 2017-05-18 22:08:49 [91807] 1dBTbE-000Nsg-Vq DANE attempt failed; no TLS connection to wrong.havedane.net [2001:1af8:4700:a118:90::7c0] 2017-05-18 22:08:50 [91807] 1dBTbE-000Nsg-Vq H=wrong.havedane.net [5.79.70.105] TLS error on connection (SSL_connect): error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed 2017-05-18 22:08:50 [91807] 1dBTbE-000Nsg-Vq DANE attempt failed; no TLS connection to wrong.havedane.net [5.79.70.105] 2017-05-18 22:08:50 [91803] 1dBTbE-000Nsg-Vq == dc6f134be71d9a96@wrong.havedane.net R=outbound_signed T=remote_dksign defer (-37) H=wrong.havedane.net [5.79.70.105]:25: failure while setting up TLS session -----------------------------8< mainlog >8------------------------------
We might still have a corner case to handle, but the critical functionality is all there, securing connections.
-Phil