DANE (RFC 6698) basically allows to publish the hash of server certificate as a TLSA record in DNS, signed with DNSSEC. A client can validate that a server's TLS certificate is owned by the same entity which controls DNSSEC signed zone.

The idea is to add a new DNS record of type TLSA to the zone, in particular a Certificate Usage DANE-EE (3).

25._tcp.mail IN TLSA 3 1 1 2c788de8eaf09f6b1f5a704a5e0718206c668f00dfca8f8112608dc25571553c

In the example, 3 is the usage (DANE-EE), 1 the selector (subject public key), 1 the matching type (SHA-256). This for my MX record, mail.pmeerw.net, port 25 (wildcard port number * would also be possible). The hash can be conveniently generated (taken from Viktor Dukhovni's tlsagen script):

openssl x509 -in /etc/letsencrypt/live/pmeerw.net/fullchain.pem -noout -pubkey | \
    openssl pkey -pubin -outform DER | \
    openssl dgst -sha256 -binary | \
    hexdump -ve '/1 "%02x"'

Since my server certificate is issued by Let's Encrypt, the certificate is renewed every 90 days or so. Because DANE essentially puts the certificate's public key into DNS, the DNS record needs to be updated whenever the key changes. Luckily, recent letsencrypt scripts (since >= 0.25.0, June 2018) support the argument renew --reuse-key, so the same keys are reused. The certificate is renewed, but not the underlying keys. Here is my weekly cron job script /etc/cron.weekly/letsencrypt:

!/bin/sh
letsencrypt renew --reuse-key --pre-hook "systemctl stop apache2" --post-hook "systemctl start apache2"
res=$(find /etc/letsencrypt/live/ -type l -mtime -1)
if [ -n "$res" ]; then
  echo "letsencrypt: new cert"
  systemctl restart apache2
  systemctl restart postfix
  systemctl restart dovecot
else
  echo "letsencrypt: nothing to do"
fi

Weirdly, the documentation is to be found with certbot -h automation, not certbot -h renew.

To verify, use the DANE SMTP validator (dane.sys4.de), see the results for pmeerw.net.

posted at: 00:24 | path: /configuration | permanent link