Gerador e verificador de registros TLSA (TLSA Record Generator and Checker)
Um registro TLSA fixa o certificado ou a chave que um serviço TLS apresenta; ele é publicado no DNS e protegido pelo DNSSEC. Servidores de e-mail usam esse registro (DANE para SMTP, RFC 7672) para recusar impostores e downgrades. Cole um certificado para obter os registros dele ou compare os registros que um domínio publica com a cadeia desse domínio.
Os certificados são lidos e os registros são calculados no seu navegador. “Consultar no DNS” envia o nome do registro (por exemplo, _25._tcp.mail.example.com) ao resolvedor DNS-over-HTTPS que você escolher (Cloudflare ou Google); certificados e registros colados nunca são enviados a lugar nenhum.
PEM (um ou mais blocos, o certificado do servidor primeiro) ou DER em base64 ou hex. Chaves privadas são recusadas.
O nome ao qual os clientes se conectam — no caso de e-mail, o nome do host MX.
Uso, seletor, tipo de correspondência e troca de chave
Publique o registro dele agora, ao lado do atual, e troque de certificado quando o registro antigo tiver expirado dos caches (RFC 7671 §8.1).
Cole um certificado, uma cadeia, uma chave pública ou um CSR e informe o nome de host.
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.