Encrypted connections are identified using certificates which are issued by certificate authorities (CA’s). In recent years a number of CA’s experienced security breaches causing certificates being issued for domains which are owned by others. Meanwhile DNSsec has become a standard which allows the DNS-based Authentication of Named Entities (DANE) to be used to verify the certificates validity.
The DANE protocol allows X.509 certificates to be tied to DNS zones using the DNSsec extension. In RFC6698 this method has been proposed as a way to authenticate TLS entities without a certificate authority. In the current DNS protocol, DANE can be applied using the TLSA record. This record type is mostly used for web-certificates (HTTPS) and secure mail-transport (SMTP) and provides an extra trust anchor for the secured connection.
The TLSA record contains information about the encryption protocol and the X.509 certificates fingerprint. The SoluteDNS TLSA Assistant can generate the fingerprint for you when providing an X.509 certificate.
The most important parameter of the TLSA record is the usage parameter. The usage defines how the fingerprint should be validated. You have the following usage options:
- 0. PKIX-TA: Certificate Authority Constraint:
Anchors a specified CA certificate in the chain of trust in addition to the normal certificate validation and must pass PKIX validation (Public-Key infrastructure). - 1. PKIX-EE: Service Certificate Constraint:
Anchors a specified server certificate in the chain of trust in addition to the normal certificate validation and must pass PKIX validation. - 2. DANE-TA: Trust Anchor Assertion:
Anchors a specified CA certificate in the chain of trust which will be considered to be the trust anchor. - 3. DANE-EE: Domain Issued Certificate:
Anchors a specified server certificate that requires to match the server certificate.
Where usage 0 and 1 become an addition to the chain of trust, the usage 2 and 3 do not. Usage 2 and 3 operate independently of the TLS validation which makes these usages useful for self-signed certificates and clients which do not validate trust anchors like SMTP clients. Usage 0 and 1 however are capable of detecting differences between trust anchors in the chain of trust which makes these usages more secure.
An example of a TLSA record:
_443._tcp.dnssec.com 3600 IN TLSA 2 0 1 8310f548d4785f30c141aa7ab4b14af93435d867cac4bb938776dca2a5a0ae04 <port> <protocol> <name> 3600 IN TLSA <usage> <selector> <type> <fingerprint>
The SoluteDNS TLSA assistant helps you in creating new TLSA records. If you want to obtain a X.509 certificate for your website you can do so by exporting the CA certificate from within your browser as X.509 certificate file. Most modern browsers allow you to export these certificates.
A thing to consider when starting to use TLSA records is they do need maintenance. If the certificate is renewed the TLSA record needs to be rolled-over as well.
Also check Common Dane Mistakes by Sys4.de. Here you can also check your SMTP servers for DANE. SIDNlabs offers a TLSA check for your website.
