After various breaches at the certificate authorities it has become clear that we need a way to authenticate a server certificate without the need to trust a third party. “DNS-based Authentication of Named Entities“ (DANE) makes this possible by publishing the certificate in the DNS. Find more information about DANE here.
In this tutorial we show an example implementation of DANE for email delivery.
What you need
- a DNSSEC capable nameserver (in this example: powerdns)
- a DNSSEC capable registrar (in this example: gandi.net)
- a mail server with TLS Support (in this example: postfix )
- to test the secured email delivery: a second mailserver with DANE support ( postfix >=2.11, DNSSEC capable resolver )
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mkdir -p /etc/postfix/ssl | |
cd /etc/postfix/ssl | |
openssl req -new -newkey rsa:1024 -days 9999 -nodes -x509 -keyout server.pem -out server.pem | |
postconf -e "smtpd_tls_security_level = may" | |
postconf -e "smtpd_tls_key_file = /etc/postfix/ssl/server.pem" | |
postconf -e "smtpd_tls_cert_file = /etc/postfix/ssl/server.pem" |
postfix/smtp[13330]: Anonymous TLS connection established to mail.example.com[...]:25: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)In order to enable DANE support, our domain’s DNS zone must be secured with DNSSEC. Our example domain is hosted on a powerdns authoritative server securing a zone on a current powerdns is pretty easy:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pdnssec show-zone example.com | |
# Zone is not actively secured | |
# Zone is not presigned | |
# No keys for zone 'example.com'. | |
pdnssec secure-zone example.com | |
# Securing zone with rsasha256 algorithm with default key size | |
# Zone example.com secured | |
# Adding NSEC ordering information |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pdnssec show-zone example.com | grep 'KSK DNSKEY' | |
# KSK DNSKEY = example.com IN DNSKEY 257 3 8 AwEAAbSNOiClmRT0LAclDwtll7hjf0jPBqMBnLJ5IzaNmg1SRa1wSbFounDhI0Mw1Gch6k/APEC629Bk4sXZM9caJF31x2e3MtjEs4n6NdSkdTVAzWI9tFT5/TsuERvbrWpFkT2h7TWWu88rP9sCl4T99bXCi11LQYSCWzDIdIlLyP2OW9+LYDi+OX6V2jCB/yg95hsnELuxrWcM+0aIEWhQVR4U821Qt+p8pa4aK2/1yprAukfkpTS9fiEvstP+kcKNSXLWE8YK8VXA6dtE/8q80qzfUnQL9pveG/Rq1mYTpwFnmeQztthk4OtiT mWwlhqaYyzZ8PAsUyKUY/WWHlf7ieU= ; ( RSASHA256 ) |
The key from the last command must be copied to the registrar. At gandi.net the form to add a DNSSEC key looks like this:
Once the key is added and synchronized on the registry’s DNS servers, you can test DNSSEC funconality at http://dnssec-debugger.verisignlabs.com/
Now, back on the mailserver hosting our domain we have to create a hash of the SSL-certificate:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
openssl x509 -in /etc/postfix/ssl/server.pem -outform DER | openssl sha256 | |
# (stdin)= 02059728e52f9a58a235584e1ed70bd2b51a44024452ec2ba0166e8fb1d1d32b |
Using this value we can add the DANE TLSA record for our mailserver in the DNS zone:
In powerdns, add a record:
Name | _25._tcp.mail.example.com (replace mail.example.com with your real mx hostname) |
Type | TLSA |
Content | 3 0 1 02059728e52f9a58a235584e1ed70bd2b51a44024452ec2ba0166e8fb1d1d32b |
the “3 0 1” means: “we took a full domain-issued certificate, and created a sha256 hash of it”. For other possible values see RFC6698 section 7.2 – 7.4.
Now we can test the new DANE TLSA records at https://www.tlsa.info
And finally, let’s test it from another postfix box. For this to work, the sending server must use a DNSSEC resolver (for example unbound) and postfix >=2.11 with DANE enabled:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
postconf -e "smtp_dns_support_level = dnssec" | |
postconf -e "smtp_tls_security_level = dane" |
and voilà, our connection is now verified even though we’re using a self-signed certificate:
postfix/smtp[17787]: Verified TLS connection established to mail.example.com[...]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
References: