TLSA

This domain publishes several TLSA records. Pick the one to work with — the certificate picker and the form below align to it. Each option shows which certificate of the served chain it pins; the record matching your currently served certificate is preselected.

The host name of the server for the selected port — e.g. www.example.com for HTTPS, mx1.example.com for SMTP, dns.example.com for DNS over TLS.

Paste the server certificate or the full chain; for DANE-TA (usage 2) the second block – the issuer – is used. Or use Load current record & certificate above to read it from your server.

After fetching, pick which certificate from the presented chain the record matches — leaf = DANE-EE (usage 3), a CA = DANE-TA (usage 2). Usage follows your choice. For DANE-TA, pin an intermediate: servers send intermediates but usually not the root, and DANE-TA requires the pinned certificate to be in the presented chain (RFC 7671 §5.2). To pin the root, use PKIX-TA (0) — it validates against the client's trust store — but PKIX usages are discouraged for SMTP (RFC 7672).

Two independent choices. PKIX (0/1) still requires the certificate to validate against a public CA — TLSA only adds a pin on top. DANE (2/3) replaces the public CA: the DNSSEC-signed record is the trust anchor, so a private or self-signed certificate works. TA (0/2) pins the issuing CA, so leaf certificates can rotate freely; EE (1/3) pins the certificate itself. For SMTP, RFC 7672 recommends DANE-EE (3) or DANE-TA (2).

The transport label in the record name (_port._proto), RFC 6698 §3. Almost always tcp. The live-certificate fetch is tcp only — for udp/sctp, paste the certificate to build the record.