Configure

TLSA record generator

Create DANE TLSA records from a certificate, pasted or fetched from your server. The default 3 1 1 record pins the public key.

Runs in your browser Everything you enter is processed locally with JavaScript and is never uploaded to ssl.sh.

Mode

Last verified

The TLSA generator creates DANE records that bind a TLS service to its certificate or public key. Paste the certificate (or fetch it from the server), keep the recommended 3 1 1, enter the service host name and port, and press Generate. You get the full record and the value to paste into your DNS panel.

How to use it

  1. Paste the server's certificate in PEM, or choose Fetch from server for direct-TLS ports such as 465 or 993.
  2. Keep the default 3 1 1 (usage 3, selector 1, matching type 1) unless you have a reason to change it.
  3. Enter the host name and port of the service, for example mail.example.com and 25.
  4. Copy the record into your DNSSEC-signed zone.

Example:

_25._tcp.mail.example.com. IN TLSA 3 1 1 0c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6

The three numbers

  • Usage: 0 PKIX-TA (CA, with normal validation), 1 PKIX-EE (server cert, with normal validation), 2 DANE-TA (your trust anchor), 3 DANE-EE (the server certificate itself).
  • Selector: 0 the full certificate, 1 only the SubjectPublicKeyInfo (public key).
  • Matching type: 0 exact data, 1 SHA-256, 2 SHA-512.

Rolling over safely

  1. Before changing the key, generate the new key's record and publish it next to the old one.
  2. Wait at least two TTLs so resolvers see both.
  3. Deploy the new certificate, then remove the old record.

DANE only works when the zone is signed with DNSSEC and the resolver validates. Check your mail server's TLS with the STARTTLS checker, and compare keys with the key matcher.

FAQ

Do browsers use TLSA records?

No. Mainstream browsers do not validate DANE. TLSA is used mainly between mail servers: Postfix, Exim and large providers check TLSA records for SMTP when the recipient domain is DNSSEC-signed.

What happens to the record when I renew the certificate?

With 3 1 1 nothing, as long as the new certificate uses the same private key (certbot --reuse-key, or the equivalent in your ACME client). If the key changes, publish the new TLSA record first, wait for the old one's TTL, then switch certificates.

Should I use 3 1 1 or 2 1 1?

3 1 1 pins your own key and does not depend on any CA. 2 1 1 pins your CA's intermediate key, which survives key changes but breaks if the CA changes its intermediate. Many operators publish both a current and a next record to make rollovers safe.

Sources

  1. RFC 6698: DANE TLSA
  2. RFC 7671: DANE operational guidance
  3. RFC 7672: SMTP Security via Opportunistic DANE TLS