TLSA Record Generator and Checker — générateur et vérificateur d’enregistrements TLSA
Un enregistrement TLSA, publié dans le DNS et protégé par DNSSEC, épingle le certificat ou la clé que présente un service TLS. Les serveurs de messagerie s’en servent (DANE pour SMTP, RFC 7672) pour rejeter les imposteurs et les attaques par repli. Collez un certificat pour obtenir ses enregistrements, ou vérifiez les enregistrements qu’un domaine publie par rapport à sa chaîne.
Les certificats sont lus et les enregistrements calculés dans votre navigateur. « Rechercher dans le DNS » envoie le nom de l’enregistrement (par exemple _25._tcp.mail.example.com) au résolveur DNS-over-HTTPS de votre choix (Cloudflare ou Google) ; les certificats et les enregistrements collés ne sont jamais envoyés nulle part.
PEM (un ou plusieurs blocs, certificat du serveur en premier), ou DER en base64 ou en hexadécimal. Les clés privées sont refusées.
Le nom auquel les clients se connectent ; pour la messagerie, le nom d’hôte MX.
Usage, sélecteur, type de correspondance et roulement de clé
Publiez son enregistrement dès maintenant, à côté de l’enregistrement actuel, et changez de certificat une fois que l’ancien enregistrement a expiré dans les caches (RFC 7671 §8.1).
Collez un certificat, une chaîne, une clé publique ou une CSR, et saisissez le nom d’hôte.
What a TLSA record says
DANE (RFC 6698) lets a domain publish, in DNS, which
certificate or key its TLS service presents. The record lives at _<port>._<protocol>.<host> — _25._tcp.mail.example.com
for a mail server, _443._tcp.www.example.com for a web server — and has three numbers and some data. The
certificate usage says what to match: 3 (DANE-EE) the server's own certificate, 2 (DANE-TA) a CA certificate in the
chain the server sends, 1 and 0 the same with the usual public-CA validation on top. The selector says whether the
whole certificate (0) or only its public key, the SubjectPublicKeyInfo (1), is matched. The matching type says
whether the data is the item itself (0) or its SHA-256 (1) or SHA-512 (2) digest.
A TLSA record only counts when the answer is signed: clients ignore records that do not validate with DNSSEC (RFC 6698 §4.1), and refuse to connect when validation fails. DANE is therefore as strong as the zone's chain of trust — which the DNSSEC inspector shows step by step.
Why 3 1 1
RFC 7671 (DANE operations) and RFC 7672 (DANE for SMTP) recommend 3 1 1: the SHA-256 digest of the server's public key. It survives a certificate renewal that keeps the key, does not depend on any CA, and ignores the certificate's names and dates — the DNSSEC signature carries the validity instead. The generator starts there, explains what changes with other combinations (a full certificate makes large answers; 2 1 x has to match a key that appears in the chain), and checks the input against the choice: a CA certificate offered for usage 3, a server certificate offered as a trust anchor, names that do not match the host, an expired certificate under a usage that checks dates.
Changing keys without an outage
Clients cache the record set for its TTL. If the server switches to a new key before the new record is everywhere, those clients refuse to connect — for mail, messages bounce. RFC 7671 §8.1 describes the safe order: publish the record of the next key next to the current one, wait at least twice the TTL, switch the server, then remove the old record. Paste the next certificate, public key or certificate request into Next certificate or key and the generator writes both records and the waiting time. A certificate request is enough: its public key is the one the next certificate will carry.
What the checker does
The checker takes TLSA records — looked up in DNS, or pasted from a zone file or dig — and the chain the server
presents, as openssl s_client -showcerts prints it. It matches every record against every certificate in the positions
its usage allows, the way a DANE client does: DANE-EE against the server certificate only, DANE-TA against a CA
certificate above it. It reports which record matches, which match nothing, which are unusable (unknown parameters or
malformed data, which RFC 6698 §4.1 tells clients to skip), whether a stronger digest makes a weaker one irrelevant
(RFC 7671 §9), and finally what a DANE client will do: connect, refuse, or ignore the records because the answer is not
signed.
The tool cannot open a TLS connection from your browser to read the chain itself — browsers do not expose server certificates to pages — so the chain is pasted. A server-side STARTTLS check of mail servers is the job of the STARTTLS checker.
What leaves your browser
Certificates, chains and pasted records are read and digests computed in your browser; they are never sent anywhere,
and private keys are refused before anything is read. Look up in DNS asks the resolver you choose — Cloudflare at
cloudflare-dns.com or Google at dns.google — for one name, such as _25._tcp.mail.example.com, with the DNSSEC OK
bit set; if the resolver answers SERVFAIL, the same question is repeated with checking disabled, to tell records whose
signatures fail from a broken server. The requests carry no cookies and no referrer, and our servers see none of it.
Share links keep the certificate, the records and the settings after the # of the address, which browsers never send.