Skip to content
MtrXTools

TLSA & SSHFP generator

Generate DANE TLSA records from a certificate or public key, with the right usage, selector and matching type for SMTP or HTTPS, and SSHFP records from an SSH public key. Runs in your browser.

What it does

  • Builds a TLSA record from a PEM certificate, a full chain or a public key: pick the leaf for usage 3 (DANE-EE) or the issuing CA for usage 2 (DANE-TA).
  • Lets you set the usage, selector and matching type, and explains which combinations work and which cause trouble.
  • Fills in the record name for common services (_25._tcp for SMTP, _443._tcp for HTTPS, 465, 587, 993, 5269) or any port, and prints the zone file line and the record data on its own.
  • Shows the matching openssl command, so you can produce the same hash on the server.
  • Builds SSHFP records from SSH host keys, known_hosts lines or ssh-keyscan output, with the SHA256: fingerprint that ssh-keygen -lf prints.

Which TLSA record to publish

For your own server, publish 3 1 1: a SHA-256 hash of the server's public key. It stays valid across certificate renewals as long as you keep the same key (for example certbot --reuse-key). 2 1 1 pins the public key of the CA that issues your certificate instead, so any certificate from that CA matches. Selector 0 (the whole certificate) changes on every renewal, and matching type 0 puts the whole certificate in DNS.

For mail, the record goes on the MX host name: _25._tcp.mail.example.com, not the mail domain. SMTP DANE (RFC 7672) only uses usages 2 and 3. TLSA and SSHFP records are only trusted when the zone is signed with DNSSEC.

Questions

What does TLSA 3 1 1 mean?
Usage 3 (DANE-EE): the record matches the server's own certificate, with no CA checks. Selector 1: it matches the public key (SubjectPublicKeyInfo), not the whole certificate. Matching type 1: the value is a SHA-256 hash. It is the most common DANE record.
How do I keep a TLSA record valid across certificate renewals?
Reuse the private key when renewing (certbot renew --reuse-key, or reuse_key = True in the renewal config) and use selector 1, so the hash doesn't change. When you do change the key, publish the new record next to the old one, wait at least the TTL, then switch the certificate.
Do I need DNSSEC for TLSA or SSHFP?
Yes. Mail servers and SSH clients ignore these records unless the answer is DNSSEC-validated, since without it anyone who can spoof DNS could also spoof the record. Check your zone with the DNS report.
How do SSH clients use SSHFP records?
With VerifyHostKeyDNS yes (or ssh -o VerifyHostKeyDNS=yes host), OpenSSH looks up the host's SSHFP records and, when they are DNSSEC-signed and match, accepts the host key without the first-connection prompt.

Related tools