OpenSSL Cookbook  3rd Edition

DNS-based Authentication of Named Entities (DANE) is a set of standards that enables you to endorse the TLS certificates you use via DNS configuration. For this to work, DANE requires DNS itself to be secure, which means that DNSSEC is necessary. Therefore, DANE is essentially a mechanism for pinning; only the certificates you approve will be accepted as valid by DANE-enabled clients. DANE itself is not controversial, but DNSSEC, on which it relies, is a very divisive topic, with the world split between those who love it and those who hate it. As a result, DANE is currently not universally supported. It’s more commonly used to secure SMTP servers; there is no support at the browser level.

Supporting DANE adds some complexity to your TLS deployments because of the way DNS configuration is propagated and cached. Before you use a new certificate you need to ensure that your new DNS configuration (endorsing that certificate) is fully propagated. Thus, you would typically first publish your DNS changes, wait for a period time sufficient for the caches to clear, and only then deploy the certificates.¹

The testing itself is straightforward; you use the s_client tool while feeding it DANE data. This is handy because it enables you to test a connection even before making DNS changes. First, let’s see what DANE configuration looks like.

DANE stores configuration in TLSA resource records, using two prefix labels to indicate the protocol and port:

$ host -t TLSA _25._tcp.mail.protonmail.ch
_25._tcp.mail.protonmail.ch has TLSA record 3 1 1 76BB66711DA416433CA890A5B2E5A0533C6006478F7D10A4469A947A CC8399E1
_25._tcp.mail.protonmail.ch has TLSA record 3 1 1 6111A5698D23C89E09C36FF833C1487EDC1B0C841F87C49DAE8F7A09 E11E979E

This output contains two endorsements, one per certificate. Having two endorsements is not unusual. For example, perhaps you might have a service that uses two certificates (e.g., one with an RSA key and another with an ECDSA key), or you have a backup certificate, or you’re simply in a transitional period when you’re switching certificates. The three numbers at the beginning indicate that the endorsement targets the certificate directly (3) via its public key (1) and a SHA256 hash (1). The rest of the data is the hash itself.

To test, you connect to the SMTP service while providing the DANE data using the -dane_tlsa_domain and -dane_tlsa_rrdata switches:

$ openssl s_client -starttls smtp \
-connect mail.protonmail.ch:25 \
-dane_tlsa_domain mail.protonmail.ch \
-dane_tlsa_rrdata "3 1 1 76BB66711DA416433CA890A5B2E5A0533C6006478F7D10A4469A947ACC8399E1"

If the verification is successful, you will see something like this in the output:

---
SSL handshake has read 5209 bytes and written 433 bytes Verification: OK Verified peername: *.protonmail.ch DANE TLSA 3 1 1 ...8f7d10a4469a947acc8399e1 matched EE certificate at depth 0
---

If you’d like to test for validation failure, just break the supplied hash. The result will be similar to the following output:

---
SSL handshake has read 5209 bytes and written 433 bytes Verification error: No matching DANE TLSA records
---

For the best results, when testing DANE in this way, always provide all known TLSA records (one per -dane_tlsa_rrdata switch). If you do, services that use multiple certificates simultaneously will check out no matter what certificate is negotiated. For TLS 1.2 and earlier, it’s possible to force a particular certificate via a choice of client-supported cipher suites (the -cipher switch). TLS 1.3 suites are different, and for this protocol version you would need to use the -sigalgs switch with a value such as ecdsa_secp256r1_sha256 or rsa_pss_rsae_sha256.