TLSA Record Generator

How to use

1. 1Keep the Build record tab selected and paste a PEM certificate, or a PEM public key if you only have the key (public keys work with selector 1 only).
2. 2Set the port, transport, and host. The owner name updates live, for example _443._tcp.www.example.com for HTTPS.
3. 3Choose usage, selector, and matching type, or click a preset like HTTPS or SMTP. The default 3 1 1 pins the leaf public key as a SHA-256 hash.
4. 4Copy the record data, the full zone-file line, or a provider snippet for BIND, Cloudflare, Route 53, or Google Cloud DNS, and use the verify block to recompute the value from your live server.
5. 5Switch to Parse and explain to paste an existing TLSA record and confirm the usage, selector, matching type, and hash length are correct.

About this tool

TLSA Record Generator turns a TLS certificate, or just its public key, into the DNS record that powers DANE (DNS-Based Authentication of Named Entities, RFC 6698). A TLSA record pins a certificate to a specific service so a client can confirm the certificate from DNS instead of, or alongside, the public certificate authority system. The owner name encodes the service as _port._transport.host, so a web server on port 443 uses _443._tcp.www.example.com, and the record data is three single-byte numbers followed by the certificate association data: usage, selector, matching type, then a hex value. Those three numbers are where people get stuck, and this tool makes each one a clear choice. Usage decides what is pinned and whether public CAs still apply: 0 (PKIX-TA) and 1 (PKIX-EE) keep normal CA validation and additionally constrain the CA or the leaf, while 2 (DANE-TA) lets you publish your own certificate as a private trust anchor and 3 (DANE-EE) pins the server's leaf certificate with no public CA required. The names PKIX-TA, PKIX-EE, DANE-TA, and DANE-EE come from RFC 7218. Selector picks the full certificate (0) or only the SubjectPublicKeyInfo (1); selector 1 is popular because the record keeps working across certificate renewals as long as you reuse the same key. Matching type is the hash applied to the selected data: 1 for SHA-256 (recommended), 2 for SHA-512, or 0 to publish the raw bytes with no hash. The most common record today is 3 1 1, a SHA-256 hash of the leaf public key. The hard mechanical work is extracting the SubjectPublicKeyInfo out of an X.509 certificate and hashing the right bytes, and this tool does both in your browser: it parses the PEM with a small built-in ASN.1 reader, walks the certificate to find the public key structure for selector 1, and computes SHA-256 or SHA-512 with the Web Crypto API. Paste a certificate (for any selector) or a bare public key (for selector 1), set the port, transport, and host, choose the three parameters or start from a preset for HTTPS, SMTP, IMAPS, or a private CA, and the tool emits the owner name, the record data, a full zone-file line with the hex wrapped the way dig and BIND show it, an openssl recipe to recompute the value from a live server, and ready-to-paste snippets for BIND, Cloudflare, Route 53, and Google Cloud DNS. A second mode parses an existing TLSA record: paste a full zone-file line or just the four values and the tool names each field, explains the effective behavior, and checks that the hash length matches the matching type, so a SHA-256 record that is not 32 bytes is flagged. Two things matter for DANE to actually protect anyone. The zone must be signed with DNSSEC, because without it the record can be stripped or forged, and you should publish a new record before rotating a certificate or key and keep both live during the change to avoid an outage. Browsers do not check TLSA today, so DANE is used mainly for SMTP (RFC 7672) and other non-browser TLS services. Everything runs locally: no DNS queries are made, and the certificates and keys you paste are never uploaded. Public certificates and public keys are safe to share by design, so no private key is ever needed.

Free to use. Works in your browser. No signup, no login.