TLSA Record Generator (DANE) & Checker

A TLSA record pins a certificate or a public key in DNS, which is what DANE is: instead of trusting whichever of a few hundred certificate authorities happens to sign for your name, a client fetches the record over DNSSEC and requires the certificate to match it. This page takes the certificate, computes the association data for every combination of selector and matching type, emits the record with its owner name, and — the part that actually gets used — tells you whether a record you already published still matches what you are serving.

Three numbers decide what a record means. Usage says whose authority the certificate rests on: 0 and 1 are PKIX, which require the certificate to validate through the public CA system as well as match the record, so a self-signed certificate fails them; 2 and 3 are DANE, which stand on their own. Selector says what is matched — the whole certificate, or just the SubjectPublicKeyInfo. Matching type says how — SHA-256, SHA-512, or the bytes themselves.

For almost every deployment the answer is 3 1 1, and the reason is operational rather than cryptographic. Selector 1 matches the public key, not the certificate, so a renewal that reuses the same key produces the same association data and the DNS record does not have to change. Selector 0 matches the certificate, so every renewal — including one that changes nothing but the dates — invalidates the record, and a record that goes stale does not degrade to unprotected: a DANE-aware client refuses the connection. Most DANE outages are exactly this.

Extracting the SubjectPublicKeyInfo is the step a tool can get subtly wrong, because it is not at a fixed offset. A certificate is a SEQUENCE whose first element is the TBSCertificate, itself a SEQUENCE of an optional explicit version, then the serial number, signature algorithm, issuer, validity and subject before the public key. The version is optional and defaults to v1, so the key is the sixth field after it or the sixth from the start — which is why this page walks the structure rather than counting bytes, and why its output is checked against the openssl command line for RSA, both P-256 and P-384, and Ed25519.

Where TLSA is worth the trouble is SMTP. RFC 7672 makes DANE the way a sending mail server decides whether to insist on TLS and which certificate to accept, and it is widely deployed there — it is what lets a receiving server be authenticated at all, given that SMTP has no equivalent of a browser address bar. For HTTPS no mainstream browser has ever shipped DANE validation, so an HTTPS TLSA record documents an intention rather than enforcing anything.

What the page does not check is everything outside the certificate. It does not fetch your DNS, so it cannot tell you the record is published, that the zone is signed, or that the parent has your DS — and without DNSSEC a TLSA record is advice an attacker can rewrite. It does not check the certificate dates either. Both belong to the deployment, not to the arithmetic.